Compare commits
194
Commits
0437943863
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
c43865cc9c | ||
|
|
987b32d2ff | ||
|
|
e1d1c70d59 | ||
|
|
4f021511fa | ||
|
|
6bde9d2726 | ||
|
|
620a8f0d91 | ||
|
|
f9284ce0a8 | ||
|
|
d4f1b529a5 | ||
|
|
9617b088bd | ||
|
|
c0d7f2f438 | ||
|
|
7229273461 | ||
|
|
d18a63aab5 | ||
|
|
7df45f7e27 | ||
|
|
0d4a812e3d | ||
|
|
2fff553518 | ||
|
|
2d516a725d | ||
|
|
cdad58ae28 | ||
|
|
9645d9c261 | ||
|
|
05e6f21a16 | ||
|
|
d762a2b76f | ||
|
|
46d7699ed0 | ||
|
|
13729bda98 | ||
|
|
b5deeaa0d5 | ||
|
|
0aa72cbce1 | ||
|
|
a72f336ad1 | ||
|
|
84634a365e | ||
|
|
2f966b1caf | ||
|
|
81ed2f0803 | ||
|
|
5bd5c521dc | ||
|
|
9cbb559ac7 | ||
|
|
b13232a21f | ||
|
|
0cd052a0a7 | ||
|
|
a2f4398f8d | ||
|
|
76e06d5951 | ||
|
|
96eabf595b | ||
|
|
430554fe0c | ||
|
|
853b85a2af | ||
|
|
1d104187f4 | ||
|
|
d018c75182 | ||
|
|
ed474c521a | ||
|
|
e8e348d478 | ||
|
|
d9fbd5b660 | ||
|
|
ca712ad4a0 | ||
|
|
a4f51c00e1 | ||
|
|
cf93e2d547 | ||
|
|
88a6c8f9ee | ||
|
|
af7b654fb7 | ||
|
|
a322e00659 | ||
|
|
ecade0dd52 | ||
|
|
3a9894cd03 | ||
|
|
4ac10ab4f6 | ||
|
|
3996ec6ef5 | ||
|
|
d1533ed31d | ||
|
|
02eb8e619f | ||
|
|
a6aceebe18 | ||
|
|
14a9b4fcc1 | ||
|
|
b70304ad6c | ||
|
|
fdb54b77ce | ||
|
|
106b07c0f0 | ||
|
|
5d7aaacc9d | ||
|
|
b4bf0f2361 | ||
|
|
365bc5d4b7 | ||
|
|
cbd0e156e7 | ||
|
|
bf9b7e65dd | ||
|
|
b516d6805f | ||
|
|
a0eaa7d6c8 | ||
|
|
17a044de0f | ||
|
|
cf38e6aabc | ||
|
|
1ef016e652 | ||
|
|
649e039164 | ||
|
|
e5944dd755 | ||
|
|
3cc438abef | ||
|
|
7d2cb93f50 | ||
|
|
00a3b2bd48 | ||
|
|
e1fe935ee4 | ||
|
|
0810699a9c | ||
|
|
69a95c05d7 | ||
|
|
3d40a6ebff | ||
|
|
6b470bab32 | ||
|
|
ee6991576d | ||
|
|
f861eae6e2 | ||
|
|
d92f5c3403 | ||
|
|
c82eba858e | ||
|
|
acb8751e92 | ||
|
|
39ff49dc47 | ||
|
|
ed71a2cd54 | ||
|
|
e174de3416 | ||
|
|
8ee519d47b | ||
|
|
16a1e16184 | ||
|
|
f5efad13a9 | ||
|
|
869630588e | ||
|
|
30733b591d | ||
|
|
456187bdab | ||
|
|
19d602699c | ||
|
|
ba72879945 | ||
|
|
db82b8a025 | ||
|
|
5ed9f001b1 | ||
|
|
18f857e1a3 | ||
|
|
61bcb5aa57 | ||
|
|
f468e30af0 | ||
|
|
7e2343ec2c | ||
|
|
3a8c6f6c80 | ||
|
|
139fbd6342 | ||
|
|
63b62c5e9f | ||
|
|
3acfdfd11f | ||
|
|
ab212db8be | ||
|
|
7102358f51 | ||
|
|
bc077bfcc8 | ||
|
|
376fcb4bb4 | ||
|
|
cc21fd9e8f | ||
|
|
affb65d7f4 | ||
|
|
32535540fe | ||
|
|
751cce0509 | ||
|
|
0732894414 | ||
|
|
d9110d03a6 | ||
|
|
76f6bd5677 | ||
|
|
32d290bea7 | ||
|
|
7fcc8a6c07 | ||
|
|
5d2ffd9163 | ||
|
|
6169efdc89 | ||
|
|
c42f2223d8 | ||
|
|
1f08820f11 | ||
|
|
2f2ea65fb4 | ||
|
|
9a60ce127b | ||
|
|
414f476620 | ||
|
|
a5f2bcde55 | ||
|
|
34ffdad00c | ||
|
|
601b85764b | ||
|
|
51b6f3d34a | ||
|
|
bddaf44ffc | ||
|
|
5209cc522e | ||
|
|
fa18b1a7c2 | ||
|
|
4b254adad2 | ||
|
|
af2e554edd | ||
|
|
facce5dbb5 | ||
|
|
2f2c0d24f6 | ||
|
|
861423c1e3 | ||
|
|
13f863ef30 | ||
|
|
2538da3f1e | ||
|
|
fa4ad6b15a | ||
|
|
5109c85a3e | ||
|
|
9975c2098b | ||
|
|
e976363259 | ||
|
|
b6e2718007 | ||
|
|
cb3eb230d6 | ||
|
|
963a5c462c | ||
|
|
82892b7a3e | ||
|
|
6f54fd07fa | ||
|
|
99b7dcee98 | ||
|
|
4f7358f4e3 | ||
|
|
0665cef7e3 | ||
|
|
48eca672a9 | ||
|
|
f159b20c87 | ||
|
|
97fe2249fe | ||
|
|
951b733ac3 | ||
|
|
531e33b0ce | ||
|
|
24c753f6e6 | ||
|
|
6880f11c26 | ||
|
|
eead4f1381 | ||
|
|
007189c0a5 | ||
|
|
f9ee1532dc | ||
|
|
ac29e62033 | ||
|
|
7eecd71a0d | ||
|
|
bb40a3cb8e | ||
|
|
4e010bc048 | ||
|
|
8c3c1aab43 | ||
|
|
cfcfd655e7 | ||
|
|
aaf8cee927 | ||
|
|
f264e924f0 | ||
|
|
a36702e5f3 | ||
|
|
01d77c153d | ||
|
|
8d227b62f6 | ||
|
|
b38fb24f14 | ||
|
|
5c64043892 | ||
|
|
11c6457559 | ||
|
|
f151747d56 | ||
|
|
49bff9de50 | ||
|
|
27b84fcd2e | ||
|
|
7e8d518946 | ||
|
|
23f2134754 | ||
|
|
4954318f7b | ||
|
|
3b22f5e1fc | ||
|
|
c188677330 | ||
|
|
58613955e4 | ||
|
|
b1770f37df | ||
|
|
2e4a9b1e08 | ||
|
|
416206e37b | ||
|
|
0a009cdc99 | ||
|
|
2ab52afc73 | ||
|
|
1aae36382c | ||
|
|
98bbec9b8d | ||
|
|
24db0e97f6 | ||
|
|
226d799eb2 | ||
|
|
e360b66c3e |
@@ -0,0 +1,148 @@
|
||||
#!/usr/bin/env node
|
||||
/**
|
||||
* Minimal MCP server for OpenAI chat completions.
|
||||
* Accepts ANY model string (gpt-5.2, gpt-5.4, etc.) — no hardcoded enum.
|
||||
* Communicates over stdio using JSON-RPC (MCP protocol).
|
||||
*/
|
||||
|
||||
import { createInterface } from "readline";
|
||||
|
||||
const OPENAI_API_KEY = process.env.OPENAI_API_KEY;
|
||||
if (!OPENAI_API_KEY) {
|
||||
process.stderr.write("ERROR: OPENAI_API_KEY environment variable is required\n");
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
const SERVER_INFO = {
|
||||
name: "openai-chat",
|
||||
version: "1.0.0",
|
||||
};
|
||||
|
||||
const TOOLS = [
|
||||
{
|
||||
name: "openai_chat",
|
||||
description:
|
||||
"Send messages to OpenAI chat completions API. Supports all OpenAI models including GPT-5.x series.",
|
||||
inputSchema: {
|
||||
type: "object",
|
||||
properties: {
|
||||
model: {
|
||||
type: "string",
|
||||
description:
|
||||
"OpenAI model name (e.g. gpt-5.2, gpt-5.4, gpt-4o, etc.)",
|
||||
default: "gpt-5.2",
|
||||
},
|
||||
messages: {
|
||||
type: "array",
|
||||
description: "Array of chat messages",
|
||||
items: {
|
||||
type: "object",
|
||||
properties: {
|
||||
role: {
|
||||
type: "string",
|
||||
enum: ["system", "user", "assistant"],
|
||||
},
|
||||
content: { type: "string" },
|
||||
},
|
||||
required: ["role", "content"],
|
||||
},
|
||||
},
|
||||
},
|
||||
required: ["messages"],
|
||||
},
|
||||
},
|
||||
];
|
||||
|
||||
async function callOpenAI(model, messages) {
|
||||
const resp = await fetch("https://api.openai.com/v1/chat/completions", {
|
||||
method: "POST",
|
||||
headers: {
|
||||
"Content-Type": "application/json",
|
||||
Authorization: `Bearer ${OPENAI_API_KEY}`,
|
||||
},
|
||||
body: JSON.stringify({ model, messages }),
|
||||
});
|
||||
|
||||
if (!resp.ok) {
|
||||
const errText = await resp.text();
|
||||
throw new Error(`OpenAI API error ${resp.status}: ${errText}`);
|
||||
}
|
||||
|
||||
const data = await resp.json();
|
||||
return data.choices?.[0]?.message?.content ?? "(no response)";
|
||||
}
|
||||
|
||||
function jsonRpcResponse(id, result) {
|
||||
return JSON.stringify({ jsonrpc: "2.0", id, result });
|
||||
}
|
||||
|
||||
function jsonRpcError(id, code, message) {
|
||||
return JSON.stringify({ jsonrpc: "2.0", id, error: { code, message } });
|
||||
}
|
||||
|
||||
async function handleRequest(req) {
|
||||
const { id, method, params } = req;
|
||||
|
||||
switch (method) {
|
||||
case "initialize":
|
||||
return jsonRpcResponse(id, {
|
||||
protocolVersion: "2024-11-05",
|
||||
capabilities: { tools: {} },
|
||||
serverInfo: SERVER_INFO,
|
||||
});
|
||||
|
||||
case "notifications/initialized":
|
||||
return null; // no response needed for notifications
|
||||
|
||||
case "tools/list":
|
||||
return jsonRpcResponse(id, { tools: TOOLS });
|
||||
|
||||
case "tools/call": {
|
||||
const toolName = params?.name;
|
||||
if (toolName !== "openai_chat") {
|
||||
return jsonRpcError(id, -32602, `Unknown tool: ${toolName}`);
|
||||
}
|
||||
const args = params?.arguments ?? {};
|
||||
const model = args.model || "gpt-5.2";
|
||||
const messages = args.messages || [];
|
||||
|
||||
if (!messages.length) {
|
||||
return jsonRpcError(id, -32602, "messages array is required");
|
||||
}
|
||||
|
||||
try {
|
||||
const content = await callOpenAI(model, messages);
|
||||
return jsonRpcResponse(id, {
|
||||
content: [{ type: "text", text: content }],
|
||||
});
|
||||
} catch (err) {
|
||||
return jsonRpcResponse(id, {
|
||||
content: [{ type: "text", text: `Error: ${err.message}` }],
|
||||
isError: true,
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
case "ping":
|
||||
return jsonRpcResponse(id, {});
|
||||
|
||||
default:
|
||||
if (method?.startsWith("notifications/")) return null;
|
||||
return jsonRpcError(id, -32601, `Method not found: ${method}`);
|
||||
}
|
||||
}
|
||||
|
||||
// stdio transport
|
||||
const rl = createInterface({ input: process.stdin });
|
||||
|
||||
rl.on("line", async (line) => {
|
||||
try {
|
||||
const req = JSON.parse(line);
|
||||
const resp = await handleRequest(req);
|
||||
if (resp) {
|
||||
process.stdout.write(resp + "\n");
|
||||
}
|
||||
} catch (err) {
|
||||
process.stderr.write(`Parse error: ${err.message}\n`);
|
||||
}
|
||||
});
|
||||
@@ -0,0 +1 @@
|
||||
{"specId": "d76705a8-fb91-4fce-b59e-c4b3b0dbbd83", "workflowType": "requirements-first", "specType": "feature"}
|
||||
@@ -0,0 +1,723 @@
|
||||
# Design Document — Dual-Pipeline Signal Engine
|
||||
|
||||
## Overview
|
||||
|
||||
The dual-pipeline signal engine is a new service at `services/signal_engine/` that runs as an independent Kubernetes deployment alongside the existing aggregation → recommendation pipeline. It implements a concurrent dual-pipeline architecture where both a heuristic (deterministic scoring) and probabilistic (Bayesian inference) pipeline evaluate the same normalized inputs per ticker per evaluation tick, producing independent BUY/WATCH/SKIP verdicts. A delta analyzer compares the two verdicts, and an output formatter assembles a structured `SignalOutput` contract published to the existing `trading_decisions` Redis queue.
|
||||
|
||||
The engine introduces several new components — Input Normalizer, Signal Library (Fibonacci, MA Stack, RSI, Cup & Handle, Elliott Wave), Multi-Timeframe Engine, Hard Filter Engine, Exit Engine, Delta Analyzer, and Output Formatter — while reusing existing infrastructure: `compute_signal_weight`, `compute_bayesian_posterior`, `classify_regime`, `WeightedSignal`, `BayesianPosterior`, and `RegimeClassification` from `services/aggregation/`.
|
||||
|
||||
The service is toggled via `dual_pipeline_enabled` in the `risk_configs` table (default: false, fail-safe). When disabled, the existing pipeline operates unchanged. When enabled, the signal engine runs alongside the existing pipeline with support for shadow mode (dual-pipeline output persisted but not forwarded to trading).
|
||||
|
||||
### Design Rationale
|
||||
|
||||
- **Separate service, not inline extension**: The signal engine has a fundamentally different evaluation cadence (multi-timeframe technical signals) and data flow (OHLCV bars, not document intelligence). Embedding it in the aggregation worker would couple two distinct concerns.
|
||||
- **Reuse existing math**: The Bayesian posterior, regime classification, and signal weighting functions are battle-tested. The probabilistic pipeline wraps them with regime-based priors and likelihood ratio accumulation rather than reimplementing.
|
||||
- **Concurrent pipelines via asyncio.gather**: Both pipelines share the same `NormalizedInput` reference and run concurrently. If one fails, the other completes normally with the failed pipeline producing a SKIP verdict.
|
||||
- **Signal clustering for correlation penalty**: The Bayesian pipeline groups signals into four clusters (momentum, structure, volatility, fundamentals) and applies exponential decay within each cluster to prevent likelihood ratio stacking inflation from correlated signals.
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
### High-Level Flow
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Evaluation Tick<br/>Redis queue: signal_engine] --> B[Input Normalizer]
|
||||
B --> C[Hard Filter Engine]
|
||||
C -->|filtered out| D[SKIP verdict for both pipelines]
|
||||
C -->|passed| E[Signal Library]
|
||||
E --> F[Multi-Timeframe Engine]
|
||||
F --> G{asyncio.gather}
|
||||
G --> H[Heuristic Pipeline]
|
||||
G --> I[Probabilistic Pipeline]
|
||||
H --> J[Delta Analyzer]
|
||||
I --> J
|
||||
J --> K[Output Formatter]
|
||||
K --> L[SignalOutput]
|
||||
L --> M[Redis: trading_decisions queue]
|
||||
L --> N[PostgreSQL: signal_engine_outputs]
|
||||
|
||||
subgraph Exit Path
|
||||
B --> O[Exit Engine]
|
||||
O --> K
|
||||
end
|
||||
```
|
||||
|
||||
### Trigger Mechanism
|
||||
|
||||
The signal engine polls a new Redis queue `stonks:queue:signal_engine`. Evaluation ticks are enqueued by the scheduler service after aggregation completes for a ticker. The queue message contains `{"ticker": "AAPL", "triggered_at": "2024-01-15T10:00:00Z"}`.
|
||||
|
||||
### Integration Points
|
||||
|
||||
| Component | Integration | Direction |
|
||||
|---|---|---|
|
||||
| Scheduler | Enqueues ticks to `signal_engine` queue | Scheduler → Signal Engine |
|
||||
| Market data tables | OHLCV bars, closing prices, returns | Signal Engine reads |
|
||||
| `macro_impact_records` | Macro bias computation | Signal Engine reads |
|
||||
| `trend_windows` | Fundamental/valuation context | Signal Engine reads |
|
||||
| `risk_configs` | Feature flags, thresholds | Signal Engine reads |
|
||||
| `classify_regime()` | Regime classification for priors | Signal Engine calls |
|
||||
| `compute_signal_weight()` | Heuristic signal weighting | Signal Engine calls |
|
||||
| `compute_bayesian_posterior()` | Bayesian accumulation | Signal Engine calls |
|
||||
| Redis `trading_decisions` | SignalOutput publication | Signal Engine → Trading Engine |
|
||||
| `signal_engine_outputs` table | Persistence for audit | Signal Engine writes |
|
||||
| Redis rolling agreement | Delta analyzer metrics | Signal Engine writes |
|
||||
|
||||
---
|
||||
|
||||
## Components and Interfaces
|
||||
|
||||
### Module Structure
|
||||
|
||||
```
|
||||
services/signal_engine/
|
||||
├── __init__.py
|
||||
├── main.py # Entry point: asyncio event loop, queue polling
|
||||
├── worker.py # Top-level orchestrator per evaluation tick
|
||||
├── config.py # SignalEngineConfig, loaded from risk_configs + env
|
||||
├── models.py # All Pydantic models (NormalizedInput, SignalResult, etc.)
|
||||
├── normalizer.py # Input Normalizer — fetches and assembles NormalizedInput
|
||||
├── signals/
|
||||
│ ├── __init__.py
|
||||
│ ├── base.py # SignalEvaluator protocol, SignalResult model
|
||||
│ ├── fibonacci.py # Fibonacci retracement evaluator
|
||||
│ ├── ma_stack.py # Moving average stack evaluator
|
||||
│ ├── rsi.py # RSI evaluator
|
||||
│ ├── cup_handle.py # Cup & Handle pattern detector
|
||||
│ └── elliott_wave.py # Elliott Wave detector
|
||||
├── confluence.py # Multi-Timeframe Confluence Engine
|
||||
├── hard_filter.py # Hard Filter Engine
|
||||
├── heuristic.py # Heuristic Pipeline (Pipeline A)
|
||||
├── probabilistic.py # Probabilistic Pipeline (Pipeline B)
|
||||
├── correlation.py # Signal cluster classification + correlation penalty
|
||||
├── exit_engine.py # Exit Engine — position-level exit management
|
||||
├── delta.py # Delta Analyzer
|
||||
├── formatter.py # Output Formatter
|
||||
└── persistence.py # Database persistence for signal_engine_outputs
|
||||
```
|
||||
|
||||
### Key Function Signatures
|
||||
|
||||
#### `main.py` — Entry Point
|
||||
|
||||
```python
|
||||
async def main() -> None:
|
||||
"""Start the signal engine worker loop.
|
||||
|
||||
Connects to PostgreSQL and Redis, loads config from risk_configs,
|
||||
and polls the signal_engine queue indefinitely.
|
||||
"""
|
||||
```
|
||||
|
||||
#### `worker.py` — Orchestrator
|
||||
|
||||
```python
|
||||
async def evaluate_tick(
|
||||
pool: asyncpg.Pool,
|
||||
redis: redis.asyncio.Redis,
|
||||
ticker: str,
|
||||
config: SignalEngineConfig,
|
||||
) -> SignalOutput | None:
|
||||
"""Run a full evaluation tick for a single ticker.
|
||||
|
||||
1. Normalize inputs
|
||||
2. Evaluate exit conditions for open positions
|
||||
3. Run hard filters
|
||||
4. Evaluate signals across timeframes
|
||||
5. Run both pipelines concurrently
|
||||
6. Compute delta analysis
|
||||
7. Format and publish output
|
||||
|
||||
Returns None if the ticker is hard-filtered or both pipelines fail.
|
||||
"""
|
||||
```
|
||||
|
||||
#### `normalizer.py` — Input Normalizer
|
||||
|
||||
```python
|
||||
async def normalize_input(
|
||||
pool: asyncpg.Pool,
|
||||
ticker: str,
|
||||
config: SignalEngineConfig,
|
||||
) -> NormalizedInput:
|
||||
"""Fetch and assemble all data needed for a single evaluation tick.
|
||||
|
||||
Sources:
|
||||
- OHLCV bars from market_data_bars (M30, H1, H4, D, W, M)
|
||||
- Fundamental metrics from trend_windows + companies
|
||||
- Macro context from macro_impact_records + global_events
|
||||
- Open position state from the trading engine's portfolio
|
||||
|
||||
Missing data sources produce sentinel values (None/empty list)
|
||||
with a logged warning.
|
||||
"""
|
||||
```
|
||||
|
||||
#### `signals/base.py` — Signal Evaluator Protocol
|
||||
|
||||
```python
|
||||
from typing import Protocol
|
||||
|
||||
class SignalEvaluator(Protocol):
|
||||
"""Protocol for all signal evaluators in the Signal Library."""
|
||||
|
||||
def evaluate(
|
||||
self,
|
||||
bars: list[OHLCVBar],
|
||||
timeframe: str,
|
||||
) -> SignalResult | None:
|
||||
"""Evaluate a signal on a single timeframe's bar data.
|
||||
|
||||
Returns None when insufficient data is available.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### `confluence.py` — Multi-Timeframe Engine
|
||||
|
||||
```python
|
||||
def compute_confluence(
|
||||
signal_results: dict[str, dict[str, SignalResult]],
|
||||
weights: dict[str, float],
|
||||
) -> list[ConfluenceSignal]:
|
||||
"""Compute weighted confluence scores across timeframes.
|
||||
|
||||
Args:
|
||||
signal_results: {signal_type: {timeframe: SignalResult}}
|
||||
weights: {timeframe: weight} e.g. {"M30": 0.03, "D": 0.30, ...}
|
||||
|
||||
Returns:
|
||||
List of ConfluenceSignal objects that pass the minimum
|
||||
confluence threshold (≥2 timeframes, ≥1 of D/W/M).
|
||||
"""
|
||||
```
|
||||
|
||||
#### `hard_filter.py` — Hard Filter Engine
|
||||
|
||||
```python
|
||||
def evaluate_hard_filters(
|
||||
normalized: NormalizedInput,
|
||||
config: HardFilterConfig,
|
||||
) -> HardFilterResult:
|
||||
"""Evaluate pre-pipeline hard filters.
|
||||
|
||||
Checks:
|
||||
- macro_bias == -1.0 → SKIP
|
||||
- valuation_score < threshold → SKIP
|
||||
- earnings_proximity_days <= threshold → SKIP
|
||||
|
||||
Returns HardFilterResult with filtered=True/False and all triggered reasons.
|
||||
"""
|
||||
```
|
||||
|
||||
#### `heuristic.py` — Heuristic Pipeline
|
||||
|
||||
```python
|
||||
def run_heuristic_pipeline(
|
||||
normalized: NormalizedInput,
|
||||
confluence_signals: list[ConfluenceSignal],
|
||||
config: HeuristicConfig,
|
||||
) -> HeuristicResult:
|
||||
"""Run the deterministic heuristic pipeline.
|
||||
|
||||
Computes S_total = S_company + S_macro + S_competitive using
|
||||
existing compute_signal_weight() and weighted sentiment averaging.
|
||||
Produces BUY/WATCH/SKIP verdict based on confidence and score thresholds.
|
||||
"""
|
||||
```
|
||||
|
||||
#### `probabilistic.py` — Probabilistic Pipeline
|
||||
|
||||
```python
|
||||
def run_probabilistic_pipeline(
|
||||
normalized: NormalizedInput,
|
||||
confluence_signals: list[ConfluenceSignal],
|
||||
regime: RegimeClassification,
|
||||
config: ProbabilisticConfig,
|
||||
) -> ProbabilisticResult:
|
||||
"""Run the Bayesian probabilistic pipeline.
|
||||
|
||||
1. Initialize regime-based prior (bull=0.58, range=0.50, bear=0.42)
|
||||
2. Compute likelihood ratios per signal with correlation penalty
|
||||
3. Accumulate via log-odds: logit(P_post) = logit(P_prior) + Σ log(LR_i)
|
||||
4. Apply entropy gating
|
||||
5. Compute EV_R = P_up · E[win_R] - (1 - P_up) · 1.0
|
||||
6. Produce BUY/WATCH/SKIP verdict
|
||||
"""
|
||||
```
|
||||
|
||||
#### `correlation.py` — Signal Correlation Penalty
|
||||
|
||||
```python
|
||||
class SignalCluster(str, Enum):
|
||||
MOMENTUM = "momentum" # MA stack, RSI
|
||||
STRUCTURE = "structure" # Fibonacci, Elliott Wave
|
||||
VOLATILITY = "volatility" # ATR-based, Bollinger-derived
|
||||
FUNDAMENTALS = "fundamentals" # valuation, earnings, macro
|
||||
|
||||
def classify_signal(signal_type: str) -> SignalCluster:
|
||||
"""Map a signal type to its correlation cluster."""
|
||||
|
||||
def apply_correlation_penalty(
|
||||
likelihood_ratios: list[LikelihoodRatio],
|
||||
) -> list[LikelihoodRatio]:
|
||||
"""Apply within-cluster decay penalty to correlated signals.
|
||||
|
||||
Within each cluster, signals are ranked by LR magnitude.
|
||||
The strongest contributes at full weight; subsequent signals
|
||||
contribute at 0.5^(n-1) decay.
|
||||
|
||||
Cross-cluster signals are independent (no penalty).
|
||||
"""
|
||||
```
|
||||
|
||||
#### `exit_engine.py` — Exit Engine
|
||||
|
||||
```python
|
||||
def evaluate_exits(
|
||||
positions: list[OpenPositionState],
|
||||
current_prices: dict[str, float],
|
||||
config: ExitConfig,
|
||||
) -> list[ExitSignal]:
|
||||
"""Evaluate exit conditions for all open positions.
|
||||
|
||||
Checks: stop_loss hit, target_1 hit (EXIT_HALF), target_2 hit (EXIT_FULL),
|
||||
trailing stop hit (EXIT_FULL for remaining).
|
||||
|
||||
Trailing stop activates after EXIT_HALF and ratchets upward only.
|
||||
"""
|
||||
```
|
||||
|
||||
#### `delta.py` — Delta Analyzer
|
||||
|
||||
```python
|
||||
async def analyze_delta(
|
||||
heuristic: HeuristicResult,
|
||||
probabilistic: ProbabilisticResult,
|
||||
redis: redis.asyncio.Redis,
|
||||
ticker: str,
|
||||
) -> DeltaResult:
|
||||
"""Compare pipeline verdicts and track agreement metrics.
|
||||
|
||||
Computes agreement flag, confidence delta, disagreement reasons.
|
||||
Updates rolling 100-evaluation agreement rate in Redis.
|
||||
Logs warning when agreement rate drops below 0.50.
|
||||
"""
|
||||
```
|
||||
|
||||
#### `formatter.py` — Output Formatter
|
||||
|
||||
```python
|
||||
def format_output(
|
||||
ticker: str,
|
||||
price: float,
|
||||
heuristic: HeuristicResult,
|
||||
probabilistic: ProbabilisticResult,
|
||||
delta: DeltaResult,
|
||||
exit_signals: list[ExitSignal],
|
||||
config: SignalEngineConfig,
|
||||
) -> SignalOutput:
|
||||
"""Assemble the structured SignalOutput contract.
|
||||
|
||||
Populates trade_plan based on verdict combination:
|
||||
- Both BUY → dual_confirmed, full position sizing
|
||||
- Probabilistic-only BUY → probabilistic_only, 50% position sizing
|
||||
- Heuristic-only BUY → standard position sizing
|
||||
- No BUY → no trade_plan (WATCH/SKIP persisted for analysis)
|
||||
"""
|
||||
|
||||
def signal_output_to_recommendation(output: SignalOutput) -> Recommendation:
|
||||
"""Map a SignalOutput to the existing Recommendation schema.
|
||||
|
||||
Enables the trading engine to consume dual-pipeline outputs
|
||||
without modification to its core evaluate_recommendation logic.
|
||||
"""
|
||||
```
|
||||
|
||||
#### `persistence.py` — Database Persistence
|
||||
|
||||
```python
|
||||
async def persist_signal_output(
|
||||
pool: asyncpg.Pool,
|
||||
output: SignalOutput,
|
||||
) -> None:
|
||||
"""Persist a SignalOutput to the signal_engine_outputs table.
|
||||
|
||||
Logs and continues on database errors (persistence failure
|
||||
does not block signal emission to the trading queue).
|
||||
"""
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data Models
|
||||
|
||||
All new data models are Pydantic `BaseModel` subclasses defined in `services/signal_engine/models.py`. Existing models (`WeightedSignal`, `BayesianPosterior`, `RegimeClassification`, `TrendSummary`, `Recommendation`, `PositionSizing`) are imported from `services/aggregation/` and `services/shared/schemas.py`.
|
||||
|
||||
### OHLCVBar
|
||||
|
||||
```python
|
||||
class OHLCVBar(BaseModel):
|
||||
"""Single OHLCV bar for a timeframe."""
|
||||
timestamp: datetime
|
||||
open: float
|
||||
high: float
|
||||
low: float
|
||||
close: float
|
||||
volume: float
|
||||
```
|
||||
|
||||
### NormalizedInput
|
||||
|
||||
```python
|
||||
class NormalizedInput(BaseModel):
|
||||
"""Unified input structure consumed by both pipelines."""
|
||||
ticker: str
|
||||
evaluated_at: datetime
|
||||
|
||||
# Multi-timeframe OHLCV bars
|
||||
bars: dict[str, list[OHLCVBar]] # {"M30": [...], "H1": [...], ...}
|
||||
|
||||
# Fundamental metrics
|
||||
valuation_score: float | None = None # [0.0, 1.0]
|
||||
earnings_proximity_days: int | None = None
|
||||
|
||||
# Macro context
|
||||
macro_bias: float = 0.0 # [-1.0, 1.0]
|
||||
|
||||
# Open position state (for exit engine)
|
||||
open_positions: list[OpenPositionState] = Field(default_factory=list)
|
||||
|
||||
# Market data for regime classification
|
||||
closing_prices: list[float] = Field(default_factory=list)
|
||||
returns: list[float] = Field(default_factory=list)
|
||||
|
||||
# Current price (latest close from shortest available timeframe)
|
||||
current_price: float | None = None
|
||||
```
|
||||
|
||||
### OpenPositionState
|
||||
|
||||
```python
|
||||
class OpenPositionState(BaseModel):
|
||||
"""Snapshot of an open position for exit evaluation."""
|
||||
position_id: str
|
||||
ticker: str
|
||||
entry_price: float
|
||||
current_price: float
|
||||
stop_loss: float
|
||||
target_1: float
|
||||
target_2: float
|
||||
trailing_stop: float | None = None
|
||||
partial_exit_done: bool = False
|
||||
atr: float | None = None
|
||||
```
|
||||
|
||||
### SignalResult
|
||||
|
||||
```python
|
||||
class SignalDirection(str, Enum):
|
||||
BULLISH = "bullish"
|
||||
BEARISH = "bearish"
|
||||
NEUTRAL = "neutral"
|
||||
|
||||
class SignalResult(BaseModel):
|
||||
"""Output from a single signal evaluator on a single timeframe."""
|
||||
signal_type: str # e.g. "fibonacci", "ma_stack", "rsi"
|
||||
timeframe: str # e.g. "D", "H4"
|
||||
strength: float = Field(ge=0.0, le=1.0)
|
||||
direction: SignalDirection
|
||||
confidence: float = Field(ge=0.0, le=1.0)
|
||||
metadata: dict = Field(default_factory=dict) # signal-specific details
|
||||
```
|
||||
|
||||
### ConfluenceSignal
|
||||
|
||||
```python
|
||||
class ConfluenceSignal(BaseModel):
|
||||
"""A signal that passed multi-timeframe confluence filtering."""
|
||||
signal_type: str
|
||||
direction: SignalDirection
|
||||
confluence_score: float # weighted sum across timeframes
|
||||
active_timeframes: list[str] # which timeframes triggered
|
||||
per_timeframe: dict[str, float] # {timeframe: strength}
|
||||
```
|
||||
|
||||
### Verdict
|
||||
|
||||
```python
|
||||
class Verdict(str, Enum):
|
||||
BUY = "BUY"
|
||||
WATCH = "WATCH"
|
||||
SKIP = "SKIP"
|
||||
```
|
||||
|
||||
### HeuristicResult
|
||||
|
||||
```python
|
||||
class HeuristicResult(BaseModel):
|
||||
"""Output from the heuristic (deterministic) pipeline."""
|
||||
verdict: Verdict
|
||||
confidence: float = Field(ge=0.0, le=1.0)
|
||||
s_total: float
|
||||
s_company: float
|
||||
s_macro: float
|
||||
s_competitive: float
|
||||
signal_weights: list[dict] = Field(default_factory=list)
|
||||
reasoning: list[str] = Field(default_factory=list)
|
||||
```
|
||||
|
||||
### LikelihoodRatio
|
||||
|
||||
```python
|
||||
class LikelihoodRatio(BaseModel):
|
||||
"""A single signal's likelihood ratio for Bayesian updating."""
|
||||
signal_type: str
|
||||
cluster: str # SignalCluster value
|
||||
lr: float # P(sig|up) / P(sig|down)
|
||||
log_lr: float # log(lr)
|
||||
penalized_log_lr: float # after correlation penalty
|
||||
hit_rate: float
|
||||
strength: float
|
||||
```
|
||||
|
||||
### ProbabilisticResult
|
||||
|
||||
```python
|
||||
class ProbabilisticResult(BaseModel):
|
||||
"""Output from the probabilistic (Bayesian) pipeline."""
|
||||
verdict: Verdict
|
||||
p_up: float = Field(ge=0.0, le=1.0)
|
||||
entropy: float = Field(ge=0.0, le=1.0)
|
||||
ev_r: float
|
||||
prior: float
|
||||
posterior: float
|
||||
likelihood_ratios: list[LikelihoodRatio] = Field(default_factory=list)
|
||||
regime: str
|
||||
reasoning: list[str] = Field(default_factory=list)
|
||||
```
|
||||
|
||||
### DeltaResult
|
||||
|
||||
```python
|
||||
class DeltaResult(BaseModel):
|
||||
"""Output from the delta analyzer comparing both pipelines."""
|
||||
agreement: bool
|
||||
confidence_delta: float
|
||||
heuristic_verdict: str
|
||||
probabilistic_verdict: str
|
||||
disagreement_reasons: list[str] = Field(default_factory=list)
|
||||
rolling_agreement_rate: float | None = None
|
||||
```
|
||||
|
||||
### ExitSignal
|
||||
|
||||
```python
|
||||
class ExitType(str, Enum):
|
||||
EXIT_HALF = "EXIT_HALF"
|
||||
EXIT_FULL = "EXIT_FULL"
|
||||
|
||||
class ExitSignal(BaseModel):
|
||||
"""An exit signal for an open position."""
|
||||
position_id: str
|
||||
ticker: str
|
||||
exit_type: ExitType
|
||||
reason: str # "stop_hit", "target_1_hit", "target_2_hit", "trailing_stop_hit"
|
||||
price: float
|
||||
```
|
||||
|
||||
### TradePlan
|
||||
|
||||
```python
|
||||
class TradePlan(BaseModel):
|
||||
"""Optional trade plan attached to a BUY signal."""
|
||||
entry_price: float
|
||||
stop_loss: float
|
||||
target_1: float
|
||||
target_2: float
|
||||
position_size_pct: float = Field(ge=0.0, le=1.0)
|
||||
max_loss_pct: float = Field(ge=0.0, le=1.0)
|
||||
dual_confirmed: bool = False
|
||||
probabilistic_only: bool = False
|
||||
```
|
||||
|
||||
### SignalOutput
|
||||
|
||||
```python
|
||||
class SignalOutput(BaseModel):
|
||||
"""The structured output contract consumed by the trading engine and audit systems."""
|
||||
output_id: str = Field(default_factory=lambda: str(uuid.uuid4()))
|
||||
ticker: str
|
||||
timestamp: datetime
|
||||
price: float
|
||||
|
||||
# Heuristic pipeline results
|
||||
heuristic_verdict: str
|
||||
heuristic_confidence: float
|
||||
heuristic_s_total: float
|
||||
|
||||
# Probabilistic pipeline results
|
||||
probabilistic_verdict: str
|
||||
probabilistic_p_up: float
|
||||
probabilistic_entropy: float
|
||||
probabilistic_ev_r: float
|
||||
|
||||
# Delta analysis
|
||||
delta_agreement: bool
|
||||
delta_confidence_delta: float
|
||||
delta_reasons: list[str] = Field(default_factory=list)
|
||||
|
||||
# Optional trade plan (populated when at least one pipeline says BUY)
|
||||
trade_plan: TradePlan | None = None
|
||||
|
||||
# Exit signals for open positions
|
||||
exit_signals: list[ExitSignal] = Field(default_factory=list)
|
||||
|
||||
# Full pipeline results for audit (stored as JSONB)
|
||||
heuristic_detail: dict = Field(default_factory=dict)
|
||||
probabilistic_detail: dict = Field(default_factory=dict)
|
||||
|
||||
# Pipeline mode metadata
|
||||
pipeline_mode: str = "dual_pipeline"
|
||||
shadow_mode: bool = False
|
||||
```
|
||||
|
||||
### SignalEngineConfig
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class SignalEngineConfig:
|
||||
"""Configuration loaded from risk_configs + environment."""
|
||||
dual_pipeline_enabled: bool = False
|
||||
heuristic_pipeline_enabled: bool = True
|
||||
probabilistic_pipeline_enabled: bool = True
|
||||
shadow_mode: bool = False
|
||||
|
||||
# Timeframe weights
|
||||
timeframe_weights: dict[str, float] = field(default_factory=lambda: {
|
||||
"M30": 0.03, "H1": 0.07, "H4": 0.15,
|
||||
"D": 0.30, "W": 0.30, "M": 0.15,
|
||||
})
|
||||
|
||||
# Hard filter thresholds
|
||||
hard_filter_valuation_min: float = 0.3
|
||||
hard_filter_earnings_days: int = 5
|
||||
hard_filter_macro_bias_skip: float = -1.0
|
||||
|
||||
# Heuristic verdict thresholds
|
||||
heuristic_buy_confidence: float = 0.70
|
||||
heuristic_buy_s_total: float = 1.2
|
||||
heuristic_buy_valuation_min: float = 0.5
|
||||
heuristic_watch_confidence: float = 0.55
|
||||
|
||||
# Probabilistic verdict thresholds
|
||||
prob_buy_p_up: float = 0.60
|
||||
prob_buy_entropy_max: float = 0.90
|
||||
prob_buy_ev_r_min: float = 1.5
|
||||
prob_buy_valuation_min: float = 0.5
|
||||
prob_watch_p_up: float = 0.55
|
||||
prob_watch_entropy_max: float = 0.95
|
||||
prob_entropy_skip: float = 0.95
|
||||
|
||||
# Regime priors
|
||||
regime_prior_bull: float = 0.58
|
||||
regime_prior_range: float = 0.50
|
||||
regime_prior_bear: float = 0.42
|
||||
|
||||
# Exit engine
|
||||
trailing_stop_atr_multiplier: float = 2.0
|
||||
|
||||
# Polling
|
||||
polling_interval_seconds: int = 30
|
||||
```
|
||||
|
||||
### HardFilterConfig / HeuristicConfig / ProbabilisticConfig / ExitConfig
|
||||
|
||||
These are derived from `SignalEngineConfig` fields for cleaner function signatures — simple `@dataclass` wrappers over the relevant subset of config values.
|
||||
|
||||
---
|
||||
|
||||
### Database Migration (039)
|
||||
|
||||
```sql
|
||||
-- Migration 039: Signal Engine Outputs
|
||||
-- Creates the signal_engine_outputs table for persisting dual-pipeline evaluations.
|
||||
|
||||
CREATE TABLE IF NOT EXISTS signal_engine_outputs (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
ticker TEXT NOT NULL,
|
||||
evaluated_at TIMESTAMPTZ NOT NULL,
|
||||
price NUMERIC NOT NULL,
|
||||
|
||||
-- Heuristic pipeline
|
||||
heuristic_verdict TEXT NOT NULL,
|
||||
heuristic_confidence NUMERIC NOT NULL,
|
||||
heuristic_s_total NUMERIC NOT NULL,
|
||||
|
||||
-- Probabilistic pipeline
|
||||
probabilistic_verdict TEXT NOT NULL,
|
||||
probabilistic_p_up NUMERIC NOT NULL,
|
||||
probabilistic_entropy NUMERIC NOT NULL,
|
||||
probabilistic_ev_r NUMERIC NOT NULL,
|
||||
|
||||
-- Delta analysis
|
||||
delta_agreement BOOLEAN NOT NULL,
|
||||
delta_confidence_delta NUMERIC NOT NULL,
|
||||
delta_reasons JSONB NOT NULL DEFAULT '[]'::jsonb,
|
||||
|
||||
-- Trade plan (null when no BUY verdict)
|
||||
trade_plan JSONB,
|
||||
|
||||
-- Full output for audit
|
||||
full_output JSONB NOT NULL,
|
||||
|
||||
-- Exit signals
|
||||
exit_signals JSONB NOT NULL DEFAULT '[]'::jsonb,
|
||||
|
||||
-- Metadata
|
||||
pipeline_mode TEXT NOT NULL DEFAULT 'dual_pipeline',
|
||||
shadow_mode BOOLEAN NOT NULL DEFAULT FALSE,
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
|
||||
);
|
||||
|
||||
-- Index for per-ticker time-range queries
|
||||
CREATE INDEX IF NOT EXISTS idx_signal_engine_outputs_ticker_time
|
||||
ON signal_engine_outputs (ticker, evaluated_at);
|
||||
|
||||
-- Index for global time-range queries
|
||||
CREATE INDEX IF NOT EXISTS idx_signal_engine_outputs_evaluated
|
||||
ON signal_engine_outputs (evaluated_at);
|
||||
|
||||
-- Index for filtering by verdict
|
||||
CREATE INDEX IF NOT EXISTS idx_signal_engine_outputs_verdicts
|
||||
ON signal_engine_outputs (heuristic_verdict, probabilistic_verdict);
|
||||
```
|
||||
|
||||
### Helm / Deployment Configuration
|
||||
|
||||
Add to `values.yaml` under `services:`:
|
||||
|
||||
```yaml
|
||||
signalEngine:
|
||||
replicas: 1
|
||||
pipeline: true
|
||||
image: signal-engine
|
||||
command: "python -m services.signal_engine.main"
|
||||
tier: processing
|
||||
secrets: [stonks-core-secrets, stonks-market-secrets]
|
||||
resources:
|
||||
requests: { cpu: 100m, memory: 128Mi }
|
||||
limits: { cpu: 500m, memory: 256Mi }
|
||||
```
|
||||
|
||||
Add to `redis_keys.py`:
|
||||
|
||||
```python
|
||||
QUEUE_SIGNAL_ENGINE = "signal_engine"
|
||||
```
|
||||
|
||||
The service uses the existing `stonks-config` ConfigMap and `stonks-core-secrets` for database/Redis credentials. No new ingress or network policy is needed — the signal engine is a queue-polling worker with no HTTP interface.
|
||||
|
||||
---
|
||||
|
||||
@@ -0,0 +1,300 @@
|
||||
# Requirements Document — Dual-Pipeline Signal Engine
|
||||
|
||||
## Introduction
|
||||
|
||||
The Stonks Oracle platform currently operates a single aggregation pipeline that can run in either heuristic or probabilistic mode (toggled via `probabilistic_scoring_enabled`). This feature replaces the single-pipeline toggle with a dual-pipeline architecture where both pipelines run concurrently per evaluation tick, produce independent verdicts (BUY/WATCH/SKIP), and emit a structured output contract for downstream consumers (trading engine, delta analysis, dashboards).
|
||||
|
||||
The dual-pipeline engine introduces:
|
||||
- **Pipeline A (Heuristic)**: Deterministic scoring using the existing `S_total = S_company + S_macro + S_competitive` formula with signal weighting, producing a confidence-gated verdict.
|
||||
- **Pipeline B (Probabilistic)**: Bayesian inference using the existing `bayesian.py` infrastructure with regime-based priors, likelihood ratios, entropy gating, and expected value calculation.
|
||||
- **Hard Filter Engine**: Pre-pipeline filters that short-circuit both pipelines before evaluation.
|
||||
- **Multi-Timeframe Engine**: Signal evaluation across M30, H1, H4, D, W, M timeframes with weighted confluence scoring.
|
||||
- **Exit Engine**: Position-level exit management (stop hit, targets, trailing ATR-based).
|
||||
- **Delta Analyzer**: Compares heuristic vs probabilistic verdicts to generate training signals for future model tuning.
|
||||
- **Output Formatter**: Structured `SignalOutput` contract consumed by the trading engine and delta analysis.
|
||||
|
||||
The design must address the signal independence assumption in the Bayesian pipeline — correlated signals (MA+RSI, Fib+Elliott) require correlation penalty or signal clustering into categories (momentum, structure, volatility, fundamentals) to prevent likelihood ratio stacking inflation.
|
||||
|
||||
## Glossary
|
||||
|
||||
- **Signal_Engine**: The top-level orchestrator in `services/signal_engine/` that coordinates input normalization, hard filters, both pipelines, delta analysis, and output formatting per evaluation tick.
|
||||
- **Heuristic_Pipeline**: Pipeline A — deterministic scoring that computes `S_total = S_company + S_macro + S_competitive` with signal weighting and produces a confidence-gated BUY/WATCH/SKIP verdict.
|
||||
- **Probabilistic_Pipeline**: Pipeline B — Bayesian inference pipeline that computes posterior probability via log-likelihood accumulation with regime-based priors, entropy gating, and expected value calculation.
|
||||
- **Input_Normalizer**: The component that ingests multi-timeframe OHLCV data, fundamentals, macro context, and open positions into a unified `NormalizedInput` structure consumed by both pipelines.
|
||||
- **Signal_Library**: The collection of technical signal evaluators (Fibonacci retracement, MA stack, RSI, Cup & Handle, Elliott Wave) that produce scored signals per timeframe.
|
||||
- **Multi_Timeframe_Engine**: The component that evaluates signals across six timeframes (M30, H1, H4, D, W, M) and computes weighted confluence scores.
|
||||
- **Hard_Filter_Engine**: The pre-pipeline filter stage that evaluates macro bias, valuation score, and earnings proximity to short-circuit evaluation before either pipeline runs.
|
||||
- **Exit_Engine**: The position management component that evaluates stop hits, take-profit targets, and trailing ATR-based stops for open positions.
|
||||
- **Delta_Analyzer**: The component that compares heuristic and probabilistic verdicts, tracks agreement rates, measures confidence deltas, and records disagreement reasons as training signals.
|
||||
- **Output_Formatter**: The component that assembles the structured `SignalOutput` contract from both pipeline results, delta analysis, and optional trade plan.
|
||||
- **SignalOutput**: The structured output contract containing ticker, timestamp, price, heuristic verdict/confidence/S_total, probabilistic verdict/P_up/entropy/EV_R, delta analysis, and optional trade plan.
|
||||
- **Verdict**: A pipeline decision of BUY, WATCH, or SKIP with associated confidence and reasoning.
|
||||
- **Confluence**: The condition where a signal triggers across multiple timeframes; requires activation on at least 2 timeframes including at least one of D, W, or M.
|
||||
- **Entropy_Gate**: Shannon entropy threshold used in the probabilistic pipeline to detect high-uncertainty states and force SKIP verdicts.
|
||||
- **EV_R**: Expected value per unit of risk, computed as `P_up · E[win_R] - (1 - P_up) · 1.0`, used as a quality gate in the probabilistic pipeline.
|
||||
- **Signal_Cluster**: A grouping of correlated signals (momentum, structure, volatility, fundamentals) used to prevent likelihood ratio stacking inflation in the Bayesian pipeline.
|
||||
- **Likelihood_Ratio**: The ratio `P(signal|up) / P(signal|down)` used in Bayesian updating, where `P(sig|up) = h·s + (1-h)·(1-s)·0.5`.
|
||||
- **Regime_Prior**: The initial probability assigned based on market regime classification: bull=0.58, range=0.50, bear=0.42.
|
||||
- **OHLCV**: Open, High, Low, Close, Volume — standard market data bar format.
|
||||
- **ATR**: Average True Range — a volatility measure used for trailing stop calculations.
|
||||
- **Fibonacci_Retracement**: A technical analysis tool computing price levels as `L(r) = SH - r·(SH - SL)` where SH is swing high, SL is swing low, and r is a retracement ratio (0.236, 0.382, 0.5, 0.618, 0.786).
|
||||
|
||||
---
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement 1: Input Normalization
|
||||
|
||||
**User Story:** As a signal engine operator, I want all market data, fundamentals, macro context, and open positions normalized into a single input structure, so that both pipelines consume identical inputs per evaluation tick.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN an evaluation tick is triggered for a ticker, THE Input_Normalizer SHALL construct a `NormalizedInput` containing multi-timeframe OHLCV bars (M30, H1, H4, D, W, M), fundamental metrics (valuation_score, earnings_proximity_days), macro context (macro_bias as float in [-1.0, 1.0]), and open position state (entry_price, current_price, stop_loss, targets).
|
||||
2. THE Input_Normalizer SHALL source OHLCV data from the existing market data tables, fundamental metrics from the existing company and trend data, and macro context from the existing `macro_impact_records` and `global_events` tables.
|
||||
3. IF any required data source is unavailable or returns an error, THEN THE Input_Normalizer SHALL populate the corresponding field with a sentinel value (`None` for optional fields, empty list for OHLCV bars) and log a warning identifying the missing source.
|
||||
4. THE Input_Normalizer SHALL validate that all OHLCV bars have monotonically increasing timestamps within each timeframe series.
|
||||
5. THE Input_Normalizer SHALL produce identical `NormalizedInput` instances for both pipelines within the same evaluation tick (shared reference, no independent fetches).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 2: Signal Library — Technical Signal Evaluation
|
||||
|
||||
**User Story:** As a quantitative analyst, I want a library of technical signal evaluators that produce scored signals per timeframe, so that both pipelines can consume standardized signal assessments.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Signal_Library SHALL implement Fibonacci retracement signal evaluation using the formula `L(r) = SH - r·(SH - SL)` for retracement ratios [0.236, 0.382, 0.5, 0.618, 0.786], where SH is the swing high and SL is the swing low within the evaluation window.
|
||||
2. THE Signal_Library SHALL implement moving average stack evaluation that detects bullish alignment (MA_10 > MA_20 > MA_50 > MA_200) and bearish alignment (MA_10 < MA_20 < MA_50 < MA_200), producing a signal strength proportional to the degree of alignment.
|
||||
3. THE Signal_Library SHALL implement RSI evaluation using the standard 14-period RSI formula, producing overbought signals (RSI > 70) and oversold signals (RSI < 30) with strength scaled by distance from the threshold.
|
||||
4. THE Signal_Library SHALL implement Cup & Handle pattern detection that identifies the cup formation (U-shaped price recovery) and handle (small consolidation), producing a signal with confidence proportional to pattern completeness.
|
||||
5. THE Signal_Library SHALL implement Elliott Wave detection that identifies impulse waves (5-wave structure) and corrective waves (3-wave structure), producing a signal with the current wave position and projected direction.
|
||||
6. WHEN a signal evaluator receives insufficient data for its calculation (fewer bars than the required lookback period), THE Signal_Library SHALL return a null signal with a reason code indicating insufficient data rather than producing a partial evaluation.
|
||||
7. FOR ALL signal evaluators, THE Signal_Library SHALL produce output conforming to a common `SignalResult` structure containing: signal_type, timeframe, strength (float in [0.0, 1.0]), direction (bullish/bearish/neutral), confidence (float in [0.0, 1.0]), and metadata specific to the signal type.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 3: Multi-Timeframe Confluence Engine
|
||||
|
||||
**User Story:** As a quantitative analyst, I want signals evaluated across multiple timeframes with weighted confluence scoring, so that the engine prioritizes signals confirmed across longer timeframes.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Multi_Timeframe_Engine SHALL evaluate each signal type across six timeframes with the following weights: M30=0.03, H1=0.07, H4=0.15, D=0.30, W=0.30, M=0.15.
|
||||
2. THE Multi_Timeframe_Engine SHALL compute a weighted confluence score as `C_confluence = Σ(w_tf · s_tf)` where `w_tf` is the timeframe weight and `s_tf` is the signal strength on that timeframe (0.0 if the signal did not trigger).
|
||||
3. WHEN a signal triggers on fewer than 2 timeframes, THE Multi_Timeframe_Engine SHALL discard the signal from further pipeline processing (minimum confluence threshold).
|
||||
4. WHEN a signal triggers on 2 or more timeframes but none of D, W, or M are included, THE Multi_Timeframe_Engine SHALL discard the signal from further pipeline processing (higher-timeframe anchor requirement).
|
||||
5. THE Multi_Timeframe_Engine SHALL pass the confluence-filtered signals and their weighted scores to both the Heuristic_Pipeline and Probabilistic_Pipeline.
|
||||
6. FOR ALL signal sets where a signal triggers on more timeframes with higher weights, THE Multi_Timeframe_Engine SHALL produce a higher confluence score (monotonicity with respect to timeframe activation count and weight).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 4: Hard Filter Engine — Pre-Pipeline Gating
|
||||
|
||||
**User Story:** As a risk manager, I want hard filters that short-circuit both pipelines before evaluation, so that clearly unfavorable conditions produce immediate SKIP verdicts without wasting computation.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN the macro_bias value from the NormalizedInput equals -1.0, THE Hard_Filter_Engine SHALL produce an immediate SKIP verdict for both pipelines with reason "macro_bias_negative".
|
||||
2. WHEN the valuation_score from the NormalizedInput is below 0.3, THE Hard_Filter_Engine SHALL produce an immediate SKIP verdict for both pipelines with reason "valuation_below_threshold".
|
||||
3. WHEN the earnings_proximity_days from the NormalizedInput is 5 or fewer, THE Hard_Filter_Engine SHALL produce an immediate SKIP verdict for both pipelines with reason "earnings_block".
|
||||
4. WHEN multiple hard filters trigger simultaneously, THE Hard_Filter_Engine SHALL record all triggered filter reasons in the SKIP verdict (not just the first).
|
||||
5. WHEN no hard filters trigger, THE Hard_Filter_Engine SHALL pass the NormalizedInput through to both pipelines without modification.
|
||||
6. THE Hard_Filter_Engine SHALL execute before either pipeline begins evaluation, and both pipelines SHALL receive the same filter decision.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 5: Heuristic Pipeline — Deterministic Scoring and Verdict
|
||||
|
||||
**User Story:** As a quantitative analyst, I want the heuristic pipeline to produce a deterministic BUY/WATCH/SKIP verdict based on composite scoring of company, macro, and competitive signals, so that the system maintains a transparent, auditable scoring path.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Heuristic_Pipeline SHALL compute a total score `S_total = S_company + S_macro + S_competitive` using the existing three-layer signal aggregation with the current `WeightedSignal` abstraction.
|
||||
2. THE Heuristic_Pipeline SHALL compute signal weights using the formula `W_signal = gate · recency · credibility · (1 + novelty) · market_context` consistent with the existing `compute_signal_weight` function in `scoring.py`.
|
||||
3. THE Heuristic_Pipeline SHALL compute a confidence value from the existing trend confidence formula incorporating source count, extraction confidence, signal agreement, and contradiction penalty.
|
||||
4. THE Heuristic_Pipeline SHALL produce a BUY verdict WHEN confidence >= 0.70 AND S_total >= 1.2 AND valuation_score >= 0.5 AND macro_bias > 0 AND earnings_proximity_days > 5.
|
||||
5. THE Heuristic_Pipeline SHALL produce a WATCH verdict WHEN confidence >= 0.55 AND the BUY conditions are not fully met.
|
||||
6. THE Heuristic_Pipeline SHALL produce a SKIP verdict WHEN confidence < 0.55.
|
||||
7. THE Heuristic_Pipeline SHALL emit a `HeuristicResult` containing: verdict (BUY/WATCH/SKIP), confidence (float), S_total (float), S_company (float), S_macro (float), S_competitive (float), signal_weights (list), and reasoning (list of strings explaining the verdict).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 6: Probabilistic Pipeline — Bayesian Inference and Verdict
|
||||
|
||||
**User Story:** As a quantitative analyst, I want the probabilistic pipeline to produce a Bayesian BUY/WATCH/SKIP verdict using regime-based priors, likelihood ratios, entropy gating, and expected value calculation, so that the system captures uncertainty structure and risk-adjusted expected outcomes.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Probabilistic_Pipeline SHALL initialize the prior probability based on the current market regime classification: bull regime → P_prior = 0.58, range regime → P_prior = 0.50, bear regime → P_prior = 0.42.
|
||||
2. THE Probabilistic_Pipeline SHALL compute likelihood ratios for each signal using `P(sig|up) = h·s + (1-h)·(1-s)·0.5` and `LR = P(sig|up) / P(sig|down)`, where h is the signal's historical hit rate and s is the signal strength.
|
||||
3. THE Probabilistic_Pipeline SHALL update the posterior using log-odds accumulation: `logit(P_post) = logit(P_prior) + Σ log(LR_i)`, converting back to probability via the sigmoid function.
|
||||
4. THE Probabilistic_Pipeline SHALL compute Shannon entropy `H = -P_up·log₂(P_up) - (1-P_up)·log₂(1-P_up)` and apply entropy gating: WHEN H > 0.95, THE Probabilistic_Pipeline SHALL force a SKIP verdict with reason "high_entropy".
|
||||
5. THE Probabilistic_Pipeline SHALL compute expected value per unit risk as `EV_R = P_up · E[win_R] - (1 - P_up) · 1.0` where `E[win_R]` is the expected win in risk units derived from signal strength and historical reward-risk ratios.
|
||||
6. THE Probabilistic_Pipeline SHALL produce a BUY verdict WHEN P_up >= 0.60 AND entropy <= 0.90 AND EV_R >= 1.5 AND macro_bias > 0 AND valuation_score >= 0.5.
|
||||
7. THE Probabilistic_Pipeline SHALL produce a WATCH verdict WHEN P_up >= 0.55 AND entropy <= 0.95 AND the BUY conditions are not fully met.
|
||||
8. THE Probabilistic_Pipeline SHALL produce a SKIP verdict in all other cases.
|
||||
9. THE Probabilistic_Pipeline SHALL emit a `ProbabilisticResult` containing: verdict (BUY/WATCH/SKIP), P_up (float), entropy (float), EV_R (float), prior (float), posterior (float), likelihood_ratios (list), regime (string), and reasoning (list of strings).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 7: Signal Correlation Penalty — Preventing LR Stacking Inflation
|
||||
|
||||
**User Story:** As a quantitative analyst, I want correlated signals grouped into clusters with a correlation penalty applied to prevent likelihood ratio stacking inflation, so that the Bayesian pipeline does not overstate confidence from redundant signals.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Probabilistic_Pipeline SHALL classify each signal into one of four clusters: momentum (MA stack, RSI), structure (Fibonacci retracement, Elliott Wave), volatility (ATR-based signals, Bollinger-derived), and fundamentals (valuation, earnings, macro).
|
||||
2. WHEN multiple signals within the same cluster produce likelihood ratios in the same direction, THE Probabilistic_Pipeline SHALL apply a within-cluster penalty: only the strongest LR in the cluster contributes at full weight, and subsequent LRs in the same cluster contribute at a decay factor of 0.5^(n-1) where n is the signal's rank within the cluster by LR magnitude.
|
||||
3. THE Probabilistic_Pipeline SHALL apply no penalty across different clusters (signals from different clusters are treated as independent).
|
||||
4. WHEN a cluster contains only one signal, THE Probabilistic_Pipeline SHALL apply no penalty to that signal.
|
||||
5. FOR ALL signal sets, THE Probabilistic_Pipeline SHALL produce a posterior probability that is less than or equal to the posterior computed without the correlation penalty (the penalty only reduces confidence, never inflates it).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 8: Exit Engine — Position Management
|
||||
|
||||
**User Story:** As a trader, I want the signal engine to evaluate exit conditions for open positions, so that stop hits, take-profit targets, and trailing stops are managed as part of the signal evaluation cycle.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN the current price of an open position hits or crosses below the stop_loss level, THE Exit_Engine SHALL emit an EXIT_FULL signal for that position with reason "stop_hit".
|
||||
2. WHEN the current price of an open position hits or crosses above the first take-profit target (target_1), THE Exit_Engine SHALL emit an EXIT_HALF signal for that position with reason "target_1_hit".
|
||||
3. WHEN the current price of an open position hits or crosses above the second take-profit target (target_2), THE Exit_Engine SHALL emit an EXIT_FULL signal for that position with reason "target_2_hit".
|
||||
4. WHEN a partial exit has been executed (EXIT_HALF), THE Exit_Engine SHALL activate a trailing stop at `current_price - ATR · trailing_multiplier` and update the trailing stop upward as the price advances (the trailing stop moves up but does not move down).
|
||||
5. WHEN the trailing stop is active and the current price crosses below the trailing stop level, THE Exit_Engine SHALL emit an EXIT_FULL signal for the remaining position with reason "trailing_stop_hit".
|
||||
6. THE Exit_Engine SHALL evaluate exit conditions before the signal pipelines run for new entry signals, so that exit signals take priority over new entry signals for the same ticker.
|
||||
7. THE Exit_Engine SHALL emit exit signals as part of the `SignalOutput` contract with the position identifier, exit type (EXIT_HALF/EXIT_FULL), and reason.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 9: Delta Analyzer — Pipeline Agreement Tracking
|
||||
|
||||
**User Story:** As a model developer, I want the delta analyzer to compare heuristic and probabilistic verdicts and record disagreement details, so that I can generate training signals for future model tuning.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN both pipelines produce verdicts for the same ticker and tick, THE Delta_Analyzer SHALL compute an agreement flag (true if both verdicts are identical, false otherwise).
|
||||
2. THE Delta_Analyzer SHALL compute a confidence delta as `|heuristic_confidence - probabilistic_P_up|` representing the magnitude of disagreement between the two pipelines.
|
||||
3. WHEN the pipelines disagree on verdict, THE Delta_Analyzer SHALL record the disagreement reason by identifying which conditions differed (e.g., "heuristic_confidence_below_threshold", "probabilistic_entropy_too_high", "EV_R_below_threshold").
|
||||
4. THE Delta_Analyzer SHALL track a rolling agreement rate over the last 100 evaluations per ticker, stored in Redis for dashboard consumption.
|
||||
5. THE Delta_Analyzer SHALL emit a `DeltaResult` containing: agreement (bool), confidence_delta (float), heuristic_verdict (string), probabilistic_verdict (string), disagreement_reasons (list of strings), and rolling_agreement_rate (float).
|
||||
6. WHEN the rolling agreement rate drops below 0.50 for a ticker, THE Delta_Analyzer SHALL log a warning indicating persistent pipeline disagreement for operator review.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 10: Output Formatter — Structured SignalOutput Contract
|
||||
|
||||
**User Story:** As a downstream system consumer, I want the signal engine to emit a structured `SignalOutput` contract, so that the trading engine, delta analysis dashboard, and audit systems can consume a consistent output format.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Output_Formatter SHALL produce a `SignalOutput` containing: ticker (string), timestamp (datetime), price (float), heuristic section (verdict, confidence, S_total), probabilistic section (verdict, P_up, entropy, EV_R), delta section (agreement, confidence_delta, disagreement_reasons), and optional trade_plan section.
|
||||
2. WHEN the heuristic pipeline produces a BUY verdict, THE Output_Formatter SHALL populate the trade_plan section with entry_price, stop_loss, target_1, target_2, and position_size derived from the heuristic confidence and existing position sizing logic.
|
||||
3. WHEN the probabilistic pipeline produces a BUY verdict but the heuristic pipeline does not, THE Output_Formatter SHALL populate the trade_plan section with a "probabilistic_only" flag and reduced position sizing (50% of standard).
|
||||
4. WHEN both pipelines produce a BUY verdict, THE Output_Formatter SHALL populate the trade_plan section with full position sizing and a "dual_confirmed" flag.
|
||||
5. THE Output_Formatter SHALL serialize the `SignalOutput` as a Pydantic model with JSON serialization support for Redis queue publishing and database persistence.
|
||||
6. FOR ALL valid pipeline results, THE Output_Formatter SHALL produce a `SignalOutput` that round-trips through JSON serialization and deserialization without data loss (parse(format(output)) produces an equivalent object).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 11: Dual Pipeline Orchestration
|
||||
|
||||
**User Story:** As a signal engine operator, I want both pipelines to run concurrently per evaluation tick sharing the same inputs, so that the system produces independent verdicts without redundant data fetching.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN an evaluation tick is triggered, THE Signal_Engine SHALL execute the Input_Normalizer once, then pass the resulting `NormalizedInput` to the Hard_Filter_Engine, then (if not filtered) execute both the Heuristic_Pipeline and Probabilistic_Pipeline concurrently using `asyncio.gather`.
|
||||
2. THE Signal_Engine SHALL enforce that both pipelines receive identical `NormalizedInput` references (no independent data fetches that could produce different snapshots).
|
||||
3. WHEN either pipeline raises an exception during evaluation, THE Signal_Engine SHALL catch the exception, log the error with full traceback, and produce a SKIP verdict for the failed pipeline with reason "pipeline_error" while allowing the other pipeline to complete normally.
|
||||
4. THE Signal_Engine SHALL measure and log the wall-clock execution time of each pipeline per tick for performance monitoring.
|
||||
5. THE Signal_Engine SHALL publish the assembled `SignalOutput` to the existing Redis queue (`stonks:queue:trading_decisions`) for consumption by the trading engine.
|
||||
6. THE Signal_Engine SHALL persist each `SignalOutput` to a database table for historical analysis and audit.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 12: Integration with Existing Trading Engine
|
||||
|
||||
**User Story:** As a platform operator, I want the dual-pipeline signal engine to integrate with the existing trading engine, so that the trading engine can consume `SignalOutput` verdicts and make execution decisions.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Signal_Engine SHALL publish `SignalOutput` to the existing `stonks:queue:trading_decisions` Redis queue in a format compatible with the existing `TradingEngine.evaluate_recommendation` interface.
|
||||
2. THE Signal_Engine SHALL map the `SignalOutput` trade_plan to the existing `Recommendation` schema fields (action, confidence, position_sizing) so that the trading engine can process dual-pipeline outputs without modification to its core evaluation logic.
|
||||
3. WHEN the `SignalOutput` has a "dual_confirmed" flag, THE Signal_Engine SHALL set the recommendation confidence to the maximum of heuristic_confidence and probabilistic_P_up.
|
||||
4. WHEN the `SignalOutput` has a "probabilistic_only" flag, THE Signal_Engine SHALL set the recommendation confidence to `probabilistic_P_up · 0.8` (20% confidence haircut for single-pipeline confirmation).
|
||||
5. WHEN neither pipeline produces a BUY verdict, THE Signal_Engine SHALL not publish a trading recommendation to the queue (WATCH and SKIP verdicts are persisted for analysis but not forwarded to the trading engine).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 13: Configuration and Feature Flags
|
||||
|
||||
**User Story:** As a platform operator, I want the dual-pipeline engine configurable via the existing `risk_configs` table and environment variables, so that I can tune thresholds, enable/disable individual pipelines, and adjust timeframe weights without code changes.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Signal_Engine SHALL support a `dual_pipeline_enabled` feature flag in `risk_configs` that toggles the entire dual-pipeline engine on or off, defaulting to false for safe rollout.
|
||||
2. THE Signal_Engine SHALL support independent enable/disable flags for each pipeline: `heuristic_pipeline_enabled` and `probabilistic_pipeline_enabled`, both defaulting to true when the dual-pipeline engine is enabled.
|
||||
3. THE Signal_Engine SHALL support configurable timeframe weights via a `timeframe_weights` JSON object in `risk_configs`, defaulting to `{"M30": 0.03, "H1": 0.07, "H4": 0.15, "D": 0.30, "W": 0.30, "M": 0.15}`.
|
||||
4. THE Signal_Engine SHALL support configurable hard filter thresholds: `hard_filter_valuation_min` (default 0.3), `hard_filter_earnings_days` (default 5), and `hard_filter_macro_bias_skip` (default -1.0).
|
||||
5. THE Signal_Engine SHALL support configurable verdict thresholds for both pipelines via `risk_configs` JSON, including heuristic confidence thresholds (BUY: 0.70, WATCH: 0.55) and probabilistic thresholds (P_up: 0.60, entropy: 0.90, EV_R: 1.5).
|
||||
6. IF the `dual_pipeline_enabled` flag fails to read from the database, THEN THE Signal_Engine SHALL default to disabled (fail-safe behavior) and log a warning.
|
||||
7. THE Signal_Engine SHALL log the active configuration at startup and on each configuration change for auditability.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 14: Regime-Based Prior Engine
|
||||
|
||||
**User Story:** As a quantitative analyst, I want the probabilistic pipeline's prior probability to adapt based on the current market regime, so that the Bayesian inference starts from a regime-appropriate baseline rather than a fixed 0.50.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Probabilistic_Pipeline SHALL use the existing `classify_regime` function from `services/aggregation/regime.py` to determine the current market regime for each ticker.
|
||||
2. THE Probabilistic_Pipeline SHALL map regime classifications to prior probabilities: trend_following with positive trend_indicator → 0.58 (bull), trend_following with negative trend_indicator → 0.42 (bear), mean_reversion → 0.50 (range), panic → 0.42 (bear), uncertainty → 0.50 (range).
|
||||
3. THE Probabilistic_Pipeline SHALL convert the regime prior to log-odds before accumulating likelihood ratios: `logit(P_prior) = log(P_prior / (1 - P_prior))`.
|
||||
4. WHEN market data is insufficient for regime classification (fewer than 100 days of price history), THE Probabilistic_Pipeline SHALL use the uncertainty prior of 0.50.
|
||||
5. THE Probabilistic_Pipeline SHALL record the regime classification and prior probability in the `ProbabilisticResult` for auditability.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 15: Database Schema for Signal Engine Output
|
||||
|
||||
**User Story:** As a platform operator, I want signal engine outputs persisted to a dedicated database table, so that historical evaluations are available for analysis, backtesting, and audit.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Signal_Engine SHALL persist each `SignalOutput` to a `signal_engine_outputs` table with columns for: id (UUID primary key), ticker (text), evaluated_at (timestamptz), price (numeric), heuristic_verdict (text), heuristic_confidence (numeric), heuristic_s_total (numeric), probabilistic_verdict (text), probabilistic_p_up (numeric), probabilistic_entropy (numeric), probabilistic_ev_r (numeric), delta_agreement (boolean), delta_confidence_delta (numeric), delta_reasons (JSONB), trade_plan (JSONB), full_output (JSONB), created_at (timestamptz).
|
||||
2. THE Signal_Engine SHALL create an index on `(ticker, evaluated_at)` for efficient time-range queries per ticker.
|
||||
3. THE Signal_Engine SHALL create an index on `evaluated_at` for efficient global time-range queries.
|
||||
4. WHEN persisting fails due to a database error, THE Signal_Engine SHALL log the error and continue processing (persistence failure does not block signal emission to the trading queue).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 16: Backward Compatibility and Migration Path
|
||||
|
||||
**User Story:** As a platform operator, I want the dual-pipeline engine to coexist with the existing single-pipeline aggregation, so that the rollout is incremental and reversible.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN `dual_pipeline_enabled` is false, THE Signal_Engine SHALL not run, and the existing aggregation pipeline SHALL continue to operate unchanged.
|
||||
2. WHEN `dual_pipeline_enabled` is true, THE Signal_Engine SHALL run alongside the existing aggregation pipeline, with the trading engine consuming `SignalOutput` from the dual-pipeline engine instead of `Recommendation` from the existing recommendation worker.
|
||||
3. THE Signal_Engine SHALL reuse the existing `WeightedSignal`, `BayesianPosterior`, `RegimeClassification`, and `TrendSummary` data structures from `services/aggregation/` rather than duplicating them.
|
||||
4. THE Signal_Engine SHALL reuse the existing `compute_signal_weight`, `compute_bayesian_posterior`, and `classify_regime` functions rather than reimplementing the underlying math.
|
||||
5. THE Signal_Engine SHALL add the new `signal_engine_outputs` table via a new database migration without modifying existing tables.
|
||||
6. THE Signal_Engine SHALL support running in "shadow mode" where both the existing pipeline and the dual-pipeline engine run, but only the existing pipeline's output is forwarded to the trading engine (dual-pipeline output is persisted for comparison only).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 17: Property-Based Testing for Dual-Pipeline Correctness
|
||||
|
||||
**User Story:** As a developer, I want comprehensive property-based tests validating the mathematical correctness and structural invariants of the dual-pipeline engine, so that edge cases and numerical stability issues are caught before deployment.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE test suite SHALL include property-based tests for the Fibonacci retracement formula verifying that `L(r) = SH - r·(SH - SL)` produces values in [SL, SH] for all r in [0, 1] and all SH > SL > 0.
|
||||
2. THE test suite SHALL include property-based tests for the Bayesian log-odds update verifying that `logit(P_post) = logit(P_prior) + Σ log(LR_i)` round-trips correctly: converting P_prior to logit, adding log-LRs, and converting back via sigmoid produces a valid probability in (0, 1).
|
||||
3. THE test suite SHALL include property-based tests for the entropy gate verifying that Shannon entropy is maximized at P_up = 0.5 and equals 0.0 at P_up = 0.0 or P_up = 1.0, and is symmetric around 0.5.
|
||||
4. THE test suite SHALL include property-based tests for the signal correlation penalty verifying that the penalized posterior is always less than or equal to the unpenalized posterior for any signal set with correlated signals.
|
||||
5. THE test suite SHALL include property-based tests for the multi-timeframe confluence score verifying monotonicity: activating a signal on an additional timeframe with non-zero weight always increases or maintains the confluence score.
|
||||
6. THE test suite SHALL include property-based tests for the `SignalOutput` contract verifying round-trip serialization: `SignalOutput.model_validate_json(output.model_dump_json())` produces an equivalent object for all valid outputs.
|
||||
7. THE test suite SHALL include property-based tests for the hard filter engine verifying that macro_bias = -1.0 always produces SKIP, valuation_score < 0.3 always produces SKIP, and earnings_proximity_days <= 5 always produces SKIP, regardless of all other input values.
|
||||
8. THE test suite SHALL include property-based tests for the EV_R calculation verifying that `EV_R = P_up · E[win_R] - (1 - P_up) · 1.0` is monotonically increasing with P_up for fixed E[win_R] > 0.
|
||||
@@ -0,0 +1,345 @@
|
||||
# Implementation Plan: Dual-Pipeline Signal Engine
|
||||
|
||||
## Overview
|
||||
|
||||
Implement the dual-pipeline signal engine as a new service at `services/signal_engine/` that runs as an independent Kubernetes deployment. The engine evaluates both a heuristic (deterministic scoring) and probabilistic (Bayesian inference) pipeline concurrently per ticker per evaluation tick, producing independent BUY/WATCH/SKIP verdicts. Implementation proceeds incrementally: infrastructure first, then core models, signal library, pipelines, orchestration, integration, and deployment.
|
||||
|
||||
## Tasks
|
||||
|
||||
- [x] 1. Project scaffolding, configuration, and data models
|
||||
- [x] 1.1 Create service directory structure and `__init__.py` files
|
||||
- Create `services/signal_engine/` with all subdirectories per the design module structure
|
||||
- Create `services/signal_engine/__init__.py`, `services/signal_engine/signals/__init__.py`
|
||||
- _Requirements: 11.1, 13.1_
|
||||
|
||||
- [x] 1.2 Implement `models.py` — all Pydantic data models
|
||||
- Define `OHLCVBar`, `NormalizedInput`, `OpenPositionState`, `SignalResult`, `SignalDirection`
|
||||
- Define `ConfluenceSignal`, `Verdict`, `HeuristicResult`, `LikelihoodRatio`, `ProbabilisticResult`
|
||||
- Define `DeltaResult`, `ExitSignal`, `ExitType`, `TradePlan`, `SignalOutput`
|
||||
- All models must use Pydantic `BaseModel` with proper field constraints (`ge`, `le`)
|
||||
- _Requirements: 1.1, 2.7, 5.7, 6.9, 9.5, 10.1, 10.5_
|
||||
|
||||
- [x] 1.3 Implement `config.py` — `SignalEngineConfig` and sub-configs
|
||||
- Define `SignalEngineConfig` dataclass with all fields from the design
|
||||
- Define `HardFilterConfig`, `HeuristicConfig`, `ProbabilisticConfig`, `ExitConfig` as derived sub-configs
|
||||
- Implement `load_config()` that reads from `risk_configs` table + environment variables
|
||||
- Default `dual_pipeline_enabled` to `False` (fail-safe)
|
||||
- _Requirements: 13.1, 13.2, 13.3, 13.4, 13.5, 13.6, 13.7_
|
||||
|
||||
- [x] 1.4 Add `QUEUE_SIGNAL_ENGINE` to `services/shared/redis_keys.py`
|
||||
- Add `QUEUE_SIGNAL_ENGINE = "signal_engine"` constant
|
||||
- _Requirements: 11.1_
|
||||
|
||||
- [x] 1.5 Write property test for `SignalOutput` round-trip serialization
|
||||
- **Requirement 17.6: SignalOutput round-trip serialization**
|
||||
- Generate arbitrary valid `SignalOutput` instances with Hypothesis
|
||||
- Verify `SignalOutput.model_validate_json(output.model_dump_json())` produces equivalent object
|
||||
- File: `tests/test_pbt_signal_engine_models.py`
|
||||
- _Requirements: 10.5, 17.6_
|
||||
|
||||
- [x] 2. Input Normalizer and Hard Filter Engine
|
||||
- [x] 2.1 Implement `normalizer.py` — Input Normalizer
|
||||
- Implement `normalize_input(pool, ticker, config) -> NormalizedInput`
|
||||
- Fetch OHLCV bars from `market_data_bars` for M30, H1, H4, D, W, M timeframes
|
||||
- Fetch fundamental metrics (valuation_score, earnings_proximity_days) from company/trend data
|
||||
- Fetch macro context (macro_bias) from `macro_impact_records` and `global_events`
|
||||
- Fetch open position state from trading engine portfolio tables
|
||||
- Populate sentinel values (`None`, empty list) for unavailable data with logged warnings
|
||||
- Validate monotonically increasing timestamps within each timeframe series
|
||||
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5_
|
||||
|
||||
- [x] 2.2 Implement `hard_filter.py` — Hard Filter Engine
|
||||
- Implement `evaluate_hard_filters(normalized, config) -> HardFilterResult`
|
||||
- Check `macro_bias == -1.0` → SKIP with reason "macro_bias_negative"
|
||||
- Check `valuation_score < 0.3` → SKIP with reason "valuation_below_threshold"
|
||||
- Check `earnings_proximity_days <= 5` → SKIP with reason "earnings_block"
|
||||
- Record all triggered filter reasons (not just first)
|
||||
- Return `HardFilterResult` with `filtered: bool` and `reasons: list[str]`
|
||||
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6_
|
||||
|
||||
- [x] 2.3 Write property tests for hard filter engine
|
||||
- **Requirement 17.7: Hard filter determinism**
|
||||
- Generate arbitrary `NormalizedInput` with `macro_bias = -1.0` → always SKIP
|
||||
- Generate arbitrary `NormalizedInput` with `valuation_score < 0.3` → always SKIP
|
||||
- Generate arbitrary `NormalizedInput` with `earnings_proximity_days <= 5` → always SKIP
|
||||
- Verify these hold regardless of all other input values
|
||||
- File: `tests/test_pbt_signal_engine_hard_filter.py`
|
||||
- _Requirements: 4.1, 4.2, 4.3, 17.7_
|
||||
|
||||
- [x] 3. Checkpoint — Ensure all tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 4. Signal Library — Technical Signal Evaluators
|
||||
- [x] 4.1 Implement `signals/base.py` — SignalEvaluator protocol
|
||||
- Define `SignalEvaluator` protocol with `evaluate(bars, timeframe) -> SignalResult | None`
|
||||
- Define common helper functions for swing high/low detection, lookback validation
|
||||
- _Requirements: 2.6, 2.7_
|
||||
|
||||
- [x] 4.2 Implement `signals/fibonacci.py` — Fibonacci retracement evaluator
|
||||
- Implement `L(r) = SH - r·(SH - SL)` for ratios [0.236, 0.382, 0.5, 0.618, 0.786]
|
||||
- Detect swing high and swing low within the evaluation window
|
||||
- Produce signal strength based on proximity of current price to retracement levels
|
||||
- Return `None` with reason code when insufficient data
|
||||
- _Requirements: 2.1, 2.6, 2.7_
|
||||
|
||||
- [x] 4.3 Write property test for Fibonacci retracement formula
|
||||
- **Requirement 17.1: Fibonacci retracement bounds**
|
||||
- For all `r` in [0, 1] and all `SH > SL > 0`, verify `L(r)` is in [SL, SH]
|
||||
- File: `tests/test_pbt_signal_engine_fibonacci.py`
|
||||
- _Requirements: 2.1, 17.1_
|
||||
|
||||
- [x] 4.4 Implement `signals/ma_stack.py` — Moving average stack evaluator
|
||||
- Detect bullish alignment (MA_10 > MA_20 > MA_50 > MA_200)
|
||||
- Detect bearish alignment (MA_10 < MA_20 < MA_50 < MA_200)
|
||||
- Produce signal strength proportional to degree of alignment
|
||||
- Return `None` when insufficient bars for MA_200 calculation
|
||||
- _Requirements: 2.2, 2.6, 2.7_
|
||||
|
||||
- [x] 4.5 Implement `signals/rsi.py` — RSI evaluator
|
||||
- Implement standard 14-period RSI formula
|
||||
- Produce overbought signals (RSI > 70) and oversold signals (RSI < 30)
|
||||
- Scale strength by distance from threshold
|
||||
- Return `None` when fewer than 14 bars available
|
||||
- _Requirements: 2.3, 2.6, 2.7_
|
||||
|
||||
- [x] 4.6 Implement `signals/cup_handle.py` — Cup & Handle pattern detector
|
||||
- Identify cup formation (U-shaped price recovery) and handle (small consolidation)
|
||||
- Produce signal with confidence proportional to pattern completeness
|
||||
- Return `None` when insufficient data or no pattern detected
|
||||
- _Requirements: 2.4, 2.6, 2.7_
|
||||
|
||||
- [x] 4.7 Implement `signals/elliott_wave.py` — Elliott Wave detector
|
||||
- Identify impulse waves (5-wave structure) and corrective waves (3-wave structure)
|
||||
- Produce signal with current wave position and projected direction
|
||||
- Return `None` when insufficient data or ambiguous wave count
|
||||
- _Requirements: 2.5, 2.6, 2.7_
|
||||
|
||||
- [x] 5. Multi-Timeframe Confluence Engine
|
||||
- [x] 5.1 Implement `confluence.py` — Multi-Timeframe Engine
|
||||
- Implement `compute_confluence(signal_results, weights) -> list[ConfluenceSignal]`
|
||||
- Compute weighted confluence score: `C_confluence = Σ(w_tf · s_tf)`
|
||||
- Apply minimum confluence threshold: discard signals triggering on < 2 timeframes
|
||||
- Apply higher-timeframe anchor: discard signals without at least one of D, W, or M
|
||||
- Return `ConfluenceSignal` objects with active timeframes and per-timeframe strengths
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6_
|
||||
|
||||
- [x] 5.2 Write property test for confluence score monotonicity
|
||||
- **Requirement 17.5: Confluence score monotonicity**
|
||||
- Verify that activating a signal on an additional timeframe with non-zero weight always increases or maintains the confluence score
|
||||
- File: `tests/test_pbt_signal_engine_confluence.py`
|
||||
- _Requirements: 3.6, 17.5_
|
||||
|
||||
- [x] 6. Checkpoint — Ensure all tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 7. Heuristic Pipeline (Pipeline A)
|
||||
- [x] 7.1 Implement `heuristic.py` — Heuristic Pipeline
|
||||
- Implement `run_heuristic_pipeline(normalized, confluence_signals, config) -> HeuristicResult`
|
||||
- Compute `S_total = S_company + S_macro + S_competitive` using existing `compute_signal_weight()`
|
||||
- Compute confidence from source count, extraction confidence, signal agreement, contradiction penalty
|
||||
- BUY verdict: confidence >= 0.70 AND S_total >= 1.2 AND valuation_score >= 0.5 AND macro_bias > 0 AND earnings_proximity_days > 5
|
||||
- WATCH verdict: confidence >= 0.55 AND BUY conditions not fully met
|
||||
- SKIP verdict: confidence < 0.55
|
||||
- Emit `HeuristicResult` with all required fields and reasoning
|
||||
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7_
|
||||
|
||||
- [x] 7.2 Write unit tests for heuristic pipeline verdict logic
|
||||
- Test BUY threshold conditions
|
||||
- Test WATCH threshold conditions
|
||||
- Test SKIP conditions
|
||||
- Test edge cases at threshold boundaries
|
||||
- File: `tests/test_signal_engine_heuristic.py`
|
||||
- _Requirements: 5.4, 5.5, 5.6_
|
||||
|
||||
- [x] 8. Probabilistic Pipeline (Pipeline B) and Correlation Penalty
|
||||
- [x] 8.1 Implement `correlation.py` — Signal cluster classification and penalty
|
||||
- Define `SignalCluster` enum: MOMENTUM, STRUCTURE, VOLATILITY, FUNDAMENTALS
|
||||
- Implement `classify_signal(signal_type) -> SignalCluster`
|
||||
- Implement `apply_correlation_penalty(likelihood_ratios) -> list[LikelihoodRatio]`
|
||||
- Within-cluster decay: strongest LR at full weight, subsequent at 0.5^(n-1)
|
||||
- No penalty across different clusters
|
||||
- Single-signal clusters receive no penalty
|
||||
- _Requirements: 7.1, 7.2, 7.3, 7.4_
|
||||
|
||||
- [x] 8.2 Implement `probabilistic.py` — Probabilistic Pipeline
|
||||
- Implement `run_probabilistic_pipeline(normalized, confluence_signals, regime, config) -> ProbabilisticResult`
|
||||
- Initialize regime-based prior: bull=0.58, range=0.50, bear=0.42
|
||||
- Compute likelihood ratios: `P(sig|up) = h·s + (1-h)·(1-s)·0.5`, `LR = P(sig|up) / P(sig|down)`
|
||||
- Apply correlation penalty via `apply_correlation_penalty()`
|
||||
- Accumulate via log-odds: `logit(P_post) = logit(P_prior) + Σ log(LR_i)`
|
||||
- Compute Shannon entropy and apply entropy gating (H > 0.95 → SKIP)
|
||||
- Compute `EV_R = P_up · E[win_R] - (1 - P_up) · 1.0`
|
||||
- BUY: P_up >= 0.60 AND entropy <= 0.90 AND EV_R >= 1.5 AND macro_bias > 0 AND valuation_score >= 0.5
|
||||
- WATCH: P_up >= 0.55 AND entropy <= 0.95 AND BUY conditions not fully met
|
||||
- SKIP: all other cases
|
||||
- Use existing `classify_regime()` from `services/aggregation/regime.py`
|
||||
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8, 6.9, 14.1, 14.2, 14.3, 14.4, 14.5_
|
||||
|
||||
- [x] 8.3 Write property test for Bayesian log-odds round-trip
|
||||
- **Requirement 17.2: Bayesian log-odds update correctness**
|
||||
- Verify `logit(P_post) = logit(P_prior) + Σ log(LR_i)` round-trips correctly
|
||||
- Converting P_prior to logit, adding log-LRs, converting back via sigmoid produces valid probability in (0, 1)
|
||||
- File: `tests/test_pbt_signal_engine_bayesian.py`
|
||||
- _Requirements: 6.3, 17.2_
|
||||
|
||||
- [x] 8.4 Write property test for entropy gate
|
||||
- **Requirement 17.3: Entropy gate properties**
|
||||
- Verify Shannon entropy is maximized at P_up = 0.5
|
||||
- Verify entropy equals 0.0 at P_up = 0.0 or P_up = 1.0
|
||||
- Verify entropy is symmetric around 0.5
|
||||
- File: `tests/test_pbt_signal_engine_bayesian.py`
|
||||
- _Requirements: 6.4, 17.3_
|
||||
|
||||
- [x] 8.5 Write property test for signal correlation penalty
|
||||
- **Requirement 17.4: Correlation penalty reduces confidence**
|
||||
- Verify penalized posterior is always <= unpenalized posterior for any signal set with correlated signals
|
||||
- File: `tests/test_pbt_signal_engine_correlation.py`
|
||||
- _Requirements: 7.5, 17.4_
|
||||
|
||||
- [x] 8.6 Write property test for EV_R monotonicity
|
||||
- **Requirement 17.8: EV_R monotonically increasing with P_up**
|
||||
- Verify `EV_R = P_up · E[win_R] - (1 - P_up) · 1.0` is monotonically increasing with P_up for fixed E[win_R] > 0
|
||||
- File: `tests/test_pbt_signal_engine_bayesian.py`
|
||||
- _Requirements: 6.5, 17.8_
|
||||
|
||||
- [x] 9. Checkpoint — Ensure all tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 10. Exit Engine
|
||||
- [x] 10.1 Implement `exit_engine.py` — Exit Engine
|
||||
- Implement `evaluate_exits(positions, current_prices, config) -> list[ExitSignal]`
|
||||
- Check stop_loss hit → EXIT_FULL with reason "stop_hit"
|
||||
- Check target_1 hit → EXIT_HALF with reason "target_1_hit"
|
||||
- Check target_2 hit → EXIT_FULL with reason "target_2_hit"
|
||||
- Trailing stop: activate after EXIT_HALF at `current_price - ATR · trailing_multiplier`
|
||||
- Trailing stop ratchets upward only (never moves down)
|
||||
- Trailing stop hit → EXIT_FULL with reason "trailing_stop_hit"
|
||||
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7_
|
||||
|
||||
- [x] 10.2 Write unit tests for exit engine
|
||||
- Test stop_loss trigger
|
||||
- Test target_1 partial exit
|
||||
- Test target_2 full exit
|
||||
- Test trailing stop activation and ratchet behavior
|
||||
- File: `tests/test_signal_engine_exit.py`
|
||||
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5_
|
||||
|
||||
- [x] 11. Delta Analyzer and Output Formatter
|
||||
- [x] 11.1 Implement `delta.py` — Delta Analyzer
|
||||
- Implement `analyze_delta(heuristic, probabilistic, redis, ticker) -> DeltaResult`
|
||||
- Compute agreement flag (both verdicts identical)
|
||||
- Compute confidence delta: `|heuristic_confidence - probabilistic_P_up|`
|
||||
- Record disagreement reasons when verdicts differ
|
||||
- Track rolling 100-evaluation agreement rate in Redis
|
||||
- Log warning when agreement rate drops below 0.50
|
||||
- _Requirements: 9.1, 9.2, 9.3, 9.4, 9.5, 9.6_
|
||||
|
||||
- [x] 11.2 Implement `formatter.py` — Output Formatter
|
||||
- Implement `format_output(ticker, price, heuristic, probabilistic, delta, exit_signals, config) -> SignalOutput`
|
||||
- Both BUY → `dual_confirmed`, full position sizing
|
||||
- Probabilistic-only BUY → `probabilistic_only`, 50% position sizing
|
||||
- Heuristic-only BUY → standard position sizing
|
||||
- No BUY → no trade_plan (WATCH/SKIP persisted for analysis)
|
||||
- Implement `signal_output_to_recommendation(output) -> Recommendation`
|
||||
- Map `SignalOutput` to existing `Recommendation` schema for trading engine compatibility
|
||||
- Dual confirmed: confidence = max(heuristic_confidence, probabilistic_P_up)
|
||||
- Probabilistic only: confidence = probabilistic_P_up · 0.8 (20% haircut)
|
||||
- _Requirements: 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 12.1, 12.2, 12.3, 12.4, 12.5_
|
||||
|
||||
- [x] 11.3 Write unit tests for output formatter
|
||||
- Test dual_confirmed trade plan generation
|
||||
- Test probabilistic_only trade plan with 50% sizing
|
||||
- Test heuristic-only trade plan
|
||||
- Test no-BUY case (no trade_plan)
|
||||
- Test `signal_output_to_recommendation` mapping
|
||||
- File: `tests/test_signal_engine_formatter.py`
|
||||
- _Requirements: 10.2, 10.3, 10.4, 12.3, 12.4_
|
||||
|
||||
- [x] 12. Orchestrator, Persistence, and Main Entry Point
|
||||
- [x] 12.1 Implement `persistence.py` — Database persistence
|
||||
- Implement `persist_signal_output(pool, output) -> None`
|
||||
- Insert into `signal_engine_outputs` table
|
||||
- Log and continue on database errors (non-blocking)
|
||||
- _Requirements: 15.1, 15.4_
|
||||
|
||||
- [x] 12.2 Implement `worker.py` — Top-level orchestrator
|
||||
- Implement `evaluate_tick(pool, redis, ticker, config) -> SignalOutput | None`
|
||||
- Step 1: Normalize inputs (single fetch, shared reference)
|
||||
- Step 2: Evaluate exit conditions for open positions
|
||||
- Step 3: Run hard filters (short-circuit if filtered)
|
||||
- Step 4: Evaluate signals across timeframes via Signal Library
|
||||
- Step 5: Compute confluence
|
||||
- Step 6: Classify regime via existing `classify_regime()`
|
||||
- Step 7: Run both pipelines concurrently via `asyncio.gather` with exception handling
|
||||
- Step 8: Compute delta analysis
|
||||
- Step 9: Format output
|
||||
- Step 10: Persist to database and publish to Redis queue
|
||||
- Catch pipeline exceptions → SKIP verdict for failed pipeline, other continues
|
||||
- Measure and log wall-clock execution time per pipeline
|
||||
- _Requirements: 11.1, 11.2, 11.3, 11.4, 11.5, 11.6_
|
||||
|
||||
- [x] 12.3 Implement `main.py` — Entry point with asyncio event loop
|
||||
- Connect to PostgreSQL (asyncpg pool) and Redis (redis.asyncio)
|
||||
- Load config from `risk_configs` table
|
||||
- Log active configuration at startup
|
||||
- Poll `stonks:queue:signal_engine` queue indefinitely
|
||||
- Check `dual_pipeline_enabled` flag; if disabled, sleep and retry
|
||||
- On config read failure, default to disabled (fail-safe)
|
||||
- Support shadow mode (persist but don't forward to trading queue)
|
||||
- _Requirements: 13.1, 13.6, 13.7, 16.1, 16.6_
|
||||
|
||||
- [x] 12.4 Write integration tests for worker orchestration
|
||||
- Test full tick evaluation with mocked DB/Redis
|
||||
- Test pipeline failure isolation (one fails, other completes)
|
||||
- Test hard filter short-circuit
|
||||
- Test shadow mode behavior
|
||||
- File: `tests/test_signal_engine_worker.py`
|
||||
- _Requirements: 11.3, 16.6_
|
||||
|
||||
- [x] 13. Checkpoint — Ensure all tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 14. Database migration and infrastructure
|
||||
- [x] 14.1 Create database migration `infra/migrations/039_signal_engine_outputs.sql`
|
||||
- Create `signal_engine_outputs` table per the design schema
|
||||
- Create index on `(ticker, evaluated_at)` for per-ticker time-range queries
|
||||
- Create index on `evaluated_at` for global time-range queries
|
||||
- Create index on `(heuristic_verdict, probabilistic_verdict)` for verdict filtering
|
||||
- _Requirements: 15.1, 15.2, 15.3_
|
||||
|
||||
- [x] 14.2 Add signal engine service to Helm chart
|
||||
- Add `signalEngine` entry to `infra/helm/stonks-oracle/values.yaml`
|
||||
- Configure: replicas=1, command=`python -m services.signal_engine.main`, tier=processing
|
||||
- Set resource requests/limits per design (100m/128Mi → 500m/256Mi)
|
||||
- Reference existing secrets: `stonks-core-secrets`, `stonks-market-secrets`
|
||||
- _Requirements: 11.1, 13.1_
|
||||
|
||||
- [x] 15. Trading engine integration and backward compatibility
|
||||
- [x] 15.1 Wire signal engine output to trading engine queue
|
||||
- Publish `SignalOutput` (mapped to `Recommendation`) to `stonks:queue:trading_decisions`
|
||||
- Only publish when at least one pipeline produces BUY verdict
|
||||
- WATCH/SKIP verdicts persisted for analysis but not forwarded
|
||||
- Ensure trading engine can consume without modification via `signal_output_to_recommendation()`
|
||||
- _Requirements: 12.1, 12.2, 12.5, 16.2_
|
||||
|
||||
- [x] 15.2 Ensure backward compatibility with existing pipeline
|
||||
- Verify `dual_pipeline_enabled=false` means signal engine does not run
|
||||
- Verify existing aggregation pipeline operates unchanged when flag is off
|
||||
- Reuse existing `WeightedSignal`, `BayesianPosterior`, `RegimeClassification` (import, don't duplicate)
|
||||
- Reuse existing `compute_signal_weight`, `compute_bayesian_posterior`, `classify_regime` functions
|
||||
- No modifications to existing tables (new migration only adds new table)
|
||||
- _Requirements: 16.1, 16.2, 16.3, 16.4, 16.5_
|
||||
|
||||
- [x] 16. Final checkpoint — Ensure all tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
## Notes
|
||||
|
||||
- Tasks marked with `*` are optional and can be skipped for faster MVP
|
||||
- Each task references specific requirements for traceability
|
||||
- Checkpoints ensure incremental validation between major phases
|
||||
- Property-based tests use Hypothesis with `@settings(max_examples=100)` per project conventions
|
||||
- PBT test files are prefixed `test_pbt_*` per project conventions
|
||||
- The service reuses existing math functions from `services/aggregation/` — no reimplementation
|
||||
- All configuration is loaded from `risk_configs` table with fail-safe defaults
|
||||
- Shadow mode allows running alongside existing pipeline without affecting trading decisions
|
||||
@@ -0,0 +1 @@
|
||||
{"specId": "ce34e647-8d91-4295-a3c0-7b001abccdee", "workflowType": "requirements-first", "specType": "feature"}
|
||||
@@ -0,0 +1,69 @@
|
||||
# Stonks Oracle Intelligence Architecture Review
|
||||
|
||||
## Recommendation
|
||||
|
||||
Add generic OpenAI-compatible support, but implement it as a protocol/capability layer rather than a third vendor-specific branch. Keep Ollama native support. Convert the existing vLLM path into an OpenAI-compatible endpoint profile.
|
||||
|
||||
For the RTX 4070 Ti SUPER cluster, do not replace the current 9B model with one smaller all-purpose model. Retain the 9B model as a focused adjudicator and split routine work into CPU-first specialist stages:
|
||||
|
||||
1. Deterministic parsing and symbol-registry resolution.
|
||||
2. GLiNER2 Large for entities, event classes, relations, and evidence spans.
|
||||
3. FinBERT for company-specific financial sentiment probabilities.
|
||||
4. Retrieval-based novelty and duplicate detection.
|
||||
5. Calibrated confidence from observed field correctness.
|
||||
6. A stock-specific tabular model trained on realized abnormal returns for impact and horizon.
|
||||
7. The existing 9B Qwen-class model for ambiguous, causal, multi-company, or implied reasoning.
|
||||
|
||||
This preserves the current reasoning ceiling, reduces average GPU inference, improves evidence fidelity, and adds stock-specific intelligence that a general language model cannot obtain from article text alone.
|
||||
|
||||
## Option Review
|
||||
|
||||
| Option | Best use | Weakness | Production role |
|
||||
|---|---|---|---|
|
||||
| Current Qwen3.5-class 9B monolith | Broad zero-shot semantics and hard reasoning | Expensive per document; stochastic; self-scores confidence/novelty/impact; weak calibration | Keep as adjudicator, not universal extractor |
|
||||
| Qwen3.5 4B | Smaller generalist | Lower reasoning ceiling with same architectural weaknesses | Benchmark only; not preferred |
|
||||
| NuExtract 1.5 3.8B | Literal schema filling | Limited implicit market reasoning; adds another generative runtime | Optional benchmark/fallback |
|
||||
| NuExtract 1.5 Smol 1.7B | Compact long-form extraction | Still autoregressive and not a sentiment/impact model | Optional CPU/on-demand filing stage |
|
||||
| NuExtract Tiny 0.5B | Very small extraction experiments | Accuracy ceiling too low for authoritative trading inputs without task tuning | Research/fine-tuning baseline |
|
||||
| GLiNER2 Large 340M | CPU-first entities, classes, relations, spans | Needs calibration and task-specific tuning for best results | Primary fast-path specialist |
|
||||
| FinBERT | Financial positive/negative/neutral probabilities | Not an extractor or reasoner | Per-company evidence sentiment |
|
||||
| Hybrid specialist + 9B | Routine precision plus retained hard-case intelligence | More engineering and observability work | Recommended architecture |
|
||||
| Hybrid + historical impact model | Text intelligence plus actual market-response learning | Requires leakage-safe dataset and monitoring | Best end-state |
|
||||
|
||||
## Highest-Priority Existing Problems
|
||||
|
||||
1. `services/extractor/vllm_client.py` ignores the supplied schema and requests only a generic JSON object.
|
||||
2. The vLLM default extraction temperature is `0.7`.
|
||||
3. Unknown provider values silently route to Ollama.
|
||||
4. Documents are truncated to 8,000 characters.
|
||||
5. The model is asked to invent authoritative novelty, confidence, impact, and horizon values.
|
||||
6. Those self-scores directly affect aggregation weighting.
|
||||
7. Provider attribution is hardcoded to Ollama.
|
||||
8. The extractor processes one job at a time at the application layer.
|
||||
9. Endpoint/model defaults conflict across code, migrations, Helm, and the vLLM deployment.
|
||||
10. A tracked Helm override contains plaintext production-like credentials and requires immediate rotation.
|
||||
|
||||
## Expected Performance Shape
|
||||
|
||||
The following are design targets to validate, not promises:
|
||||
|
||||
- 60-80% of representative documents accepted through the CPU fast path after calibration.
|
||||
- 2x or greater reduction in GPU-seconds per accepted document.
|
||||
- Peak GPU memory near the current 9B deployment because no second generative model is permanently GPU-resident.
|
||||
- p50 latency substantially lower for routine documents.
|
||||
- p95 latency near the current model path for adjudicated documents.
|
||||
- Better exact-field and evidence accuracy from deterministic/specialist stages.
|
||||
- Same broad semantic ceiling because the 9B model remains available.
|
||||
- Better impact/horizon calibration once the historical outcome model is approved.
|
||||
|
||||
## Immediate Next Decision
|
||||
|
||||
The first implementation milestone should not be GLiNER integration. It should be:
|
||||
|
||||
1. Rotate exposed credentials.
|
||||
2. Establish the real runtime model/configuration.
|
||||
3. Fix strict JSON Schema output and temperature on the current 9B endpoint.
|
||||
4. Build the gold corpus and replay harness.
|
||||
5. Then implement the gateway and specialist shadow path.
|
||||
|
||||
That order creates a fair baseline and prevents the project from attributing simple request fixes to the new architecture.
|
||||
@@ -0,0 +1,792 @@
|
||||
# Design Document
|
||||
|
||||
## Overview
|
||||
|
||||
Intelligence Pipeline v3 replaces a monolithic "article to final trading-oriented JSON" request with a staged evidence and prediction architecture. The existing 9B model remains available, but its role changes from universal extractor and self-scorer to **semantic adjudicator** for the minority of documents that need broad language understanding.
|
||||
|
||||
The design intentionally chooses the best long-term architecture rather than the minimum code change:
|
||||
|
||||
- Generic OpenAI-compatible support is implemented as a capability-aware gateway, not another provider branch.
|
||||
- Explicit facts, entities, numbers, and sentiment are produced by CPU-first specialist components.
|
||||
- Novelty comes from retrieval and similarity.
|
||||
- Confidence comes from empirical calibration.
|
||||
- Impact and horizon come from a stock-specific model trained against realized outcomes.
|
||||
- The existing 9B vLLM model handles ambiguity, causality, implication, and conflicts.
|
||||
- Every field retains source evidence and model lineage.
|
||||
|
||||
## Repository Review Findings
|
||||
|
||||
The following findings materially shaped this design:
|
||||
|
||||
| Finding | Repository location | Consequence |
|
||||
|---|---|---|
|
||||
| The vLLM client receives a JSON Schema but sends only `response_format: {"type": "json_object"}`. | `services/extractor/vllm_client.py:63-91` | The server is not constraining generation to the actual schema. |
|
||||
| vLLM extraction defaults to temperature `0.7`. | `services/shared/config.py:64-71`, `services/shared/config.py:284-291` | Routine extraction is needlessly stochastic. |
|
||||
| Unknown provider values silently fall back to Ollama. | `services/extractor/llm_factory.py:1-6`, `services/extractor/llm_factory.py:47-67` | Configuration mistakes can invoke the wrong endpoint without failing. |
|
||||
| Long documents are truncated to the first 8,000 characters. | `services/extractor/prompts.py:102-105` | Filings, transcripts, and long articles can lose material facts. |
|
||||
| The prompt asks one model for summary, entities, relevance, sentiment, impact, horizon, novelty, confidence, and evidence. | `services/extractor/prompts.py:107-126` | Extraction, reasoning, prediction, and self-evaluation are coupled. |
|
||||
| The prompt supplies tracked tickers and invites inferred sector/theme exposure. | `services/extractor/prompts.py:85-98` | Explicit mentions and inferred exposure are mixed before evidence validation. |
|
||||
| Persisted provider attribution is hardcoded to `ollama`, including failures. | `services/extractor/worker.py:166-184`, `services/extractor/worker.py:227-244` | Audit and model-performance attribution are incorrect for vLLM. |
|
||||
| A single worker loop pops and processes one job at a time. | `services/extractor/main.py:438-468`, invocation near `services/extractor/main.py:628` | Application-level parallelism is constrained even if vLLM supports batching. |
|
||||
| Runtime refresh mutates a client's private `_config`. | `services/extractor/main.py:496-531` | The protocol does not expose lifecycle or reconfiguration cleanly. |
|
||||
| The thesis rewriter reimplements Ollama/vLLM branching. | `services/recommendation/thesis_llm.py:87-200` | Provider support is duplicated and will continue drifting. |
|
||||
| Model defaults conflict across Python config, database migrations, Helm values, and the standalone vLLM deployment. | `services/shared/config.py`, `infra/migrations`, `infra/helm/stonks-oracle/values.yaml`, `infra/kube-vllm/deployment.yaml` | The repository cannot prove which model is canonical at runtime. |
|
||||
| Model-produced novelty and confidence directly affect aggregation weight; model-produced impact is reused as sentiment strength and impact. | `services/aggregation/scoring.py:436-529`, `services/aggregation/worker.py:430-463` | Uncalibrated model self-scores can materially influence downstream signals. |
|
||||
| A tracked Helm override contains plaintext production-like credentials. | `infra/helm/stonks-oracle/values-live-math.yaml` | Immediate rotation and history remediation are required before feature work ships. |
|
||||
|
||||
The existing test suite around the LLM clients is useful. The focused provider tests passed after installing the declared dependencies plus the missing property-test dependency, but they encode current behavior and do not test true schema-constrained vLLM output.
|
||||
|
||||
## Decision Summary
|
||||
|
||||
### 1. Add generic OpenAI-compatible support
|
||||
|
||||
Yes, but do not add an `OpenAIClient` beside `VLLMClient` and `OllamaClient`. Rename the concept:
|
||||
|
||||
- `OllamaNativeClient` for `/api/chat` and Ollama-specific controls.
|
||||
- `OpenAICompatibleClient` for `/v1/chat/completions` and optionally `/v1/responses` after a separate compatibility gate.
|
||||
- `SpecialistHttpClient` for typed non-generative endpoints.
|
||||
|
||||
`vllm` becomes a profile alias whose protocol is `openai_chat`. Hosted OpenAI, LM Studio, SGLang, LocalAI, or another compatible server can be represented by endpoint capabilities rather than new `if provider == ...` branches.
|
||||
|
||||
Use direct `httpx` requests in the generic layer. This keeps the wire payload explicit, permits provider-specific `extra_body`, simplifies redacted request auditing, and avoids binding every compatible server to one SDK's assumptions.
|
||||
|
||||
### 2. Retain the 9B model, but stop using it for every stage
|
||||
|
||||
The RTX 4070 Ti SUPER remains dedicated to one 9B-class vLLM deployment. This preserves the current semantic ceiling and current peak VRAM class. The 9B model is invoked only for ambiguous cases and receives a compressed evidence packet rather than the raw entire document and ticker universe.
|
||||
|
||||
### 3. Use a CPU-first fast path
|
||||
|
||||
Run the following on CPU nodes:
|
||||
|
||||
- GLiNER2 Large candidate for entities, event classes, relations, and schema-oriented extraction.
|
||||
- FinBERT candidate for company-specific positive/negative/neutral probabilities.
|
||||
- Deterministic parsers and the existing symbol registry for numeric facts and ticker identity.
|
||||
- Compact embeddings plus fingerprints for novelty and deduplication.
|
||||
- A calibrated tabular impact model for market direction, magnitude, and horizon.
|
||||
|
||||
NuExtract 1.5 Smol is retained as an evaluated optional stage for long-form or hierarchical extraction. It is not made a second always-resident GPU model because the intended deployment should preserve the 9B model's GPU footprint and because GLiNER2 plus deterministic parsing may already cover most literal extraction.
|
||||
|
||||
## Architecture
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Normalized document] --> B[Segmenter and offset map]
|
||||
B --> C[Deterministic candidates\ncompany aliases, tickers, numbers, dates]
|
||||
B --> D[GLiNER2 specialist\nentities, events, relations, facts]
|
||||
C --> E[Symbol resolver]
|
||||
D --> E
|
||||
E --> F[Evidence linker and verifier]
|
||||
F --> G[FinBERT per-company sentiment]
|
||||
F --> H[Novelty and dedup retrieval]
|
||||
G --> I[Confidence calibrator]
|
||||
H --> I
|
||||
I --> J{Fast-path acceptance?}
|
||||
J -->|yes| K[Approved evidence graph]
|
||||
J -->|no| L[9B Qwen adjudicator on vLLM]
|
||||
L --> M[Post-adjudication verifier]
|
||||
M --> K
|
||||
K --> N[Stock-specific impact model]
|
||||
N --> O[v3 intelligence records]
|
||||
O --> P[Compatibility adapter]
|
||||
P --> Q[Current aggregation and recommendation consumers]
|
||||
```
|
||||
|
||||
### Why this can be more intelligent without a larger footprint
|
||||
|
||||
A monolithic 9B model is broadly intelligent but is not necessarily the best estimator for every subproblem. The v3 design keeps that model for tasks requiring broad semantics while giving narrower jobs to components whose output can be calibrated and verified. The impact model adds information the language model does not have: observed historical market response. The result is not merely a smaller extractor; it is a system that combines textual reasoning with market-specific learned behavior.
|
||||
|
||||
## Component Design
|
||||
|
||||
### A. Inference Gateway
|
||||
|
||||
#### Package layout
|
||||
|
||||
```text
|
||||
services/shared/inference/
|
||||
├── protocol.py
|
||||
├── models.py
|
||||
├── registry.py
|
||||
├── router.py
|
||||
├── capabilities.py
|
||||
├── errors.py
|
||||
├── redaction.py
|
||||
└── clients/
|
||||
├── ollama_native.py
|
||||
├── openai_compatible.py
|
||||
└── specialist_http.py
|
||||
```
|
||||
|
||||
#### Core types
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class ProviderCapabilities:
|
||||
chat_completions: bool
|
||||
responses_api: bool
|
||||
json_schema: bool
|
||||
json_object: bool
|
||||
seed: bool
|
||||
usage: bool
|
||||
max_completion_tokens: bool
|
||||
reasoning_toggle: bool
|
||||
model_listing: bool
|
||||
|
||||
@dataclass(frozen=True)
|
||||
class InferenceTarget:
|
||||
endpoint_id: UUID
|
||||
deployment_id: UUID
|
||||
protocol: Literal["ollama_native", "openai_chat", "specialist_http"]
|
||||
base_url: str
|
||||
model: str
|
||||
capabilities: ProviderCapabilities
|
||||
auth_secret_ref: str | None
|
||||
extra_headers: Mapping[str, str]
|
||||
extra_body: Mapping[str, Any]
|
||||
|
||||
@dataclass
|
||||
class StructuredGenerationRequest:
|
||||
messages: list[ChatMessage]
|
||||
json_schema: dict[str, Any] | None
|
||||
max_output_tokens: int
|
||||
temperature: float = 0.0
|
||||
seed: int | None = 0
|
||||
timeout_seconds: float = 120.0
|
||||
trace_id: str = ""
|
||||
|
||||
@dataclass
|
||||
class InferenceResult:
|
||||
content: str
|
||||
parsed: dict[str, Any] | None
|
||||
target: InferenceTarget
|
||||
structured_mode: Literal["json_schema", "json_object", "prompt_only", "none"]
|
||||
latency_ms: int
|
||||
input_tokens: int | None
|
||||
output_tokens: int | None
|
||||
request_id: str | None
|
||||
repaired: bool
|
||||
retries: int
|
||||
```
|
||||
|
||||
#### OpenAI-compatible structured output
|
||||
|
||||
The client chooses the strongest declared mode:
|
||||
|
||||
1. `json_schema`: send the actual schema and strict mode.
|
||||
2. `json_object`: allow only if the deployment profile explicitly permits it.
|
||||
3. `prompt_only`: allow only for experiments or legacy fallback.
|
||||
|
||||
For current vLLM versions, the gateway should support both standard `response_format` JSON Schema and a configurable vLLM `structured_outputs` extra body because deployed versions may differ. The endpoint profile records which wire form passed its capability probe.
|
||||
|
||||
Example standard payload:
|
||||
|
||||
```json
|
||||
{
|
||||
"model": "AxionML/Qwen3.5-9B-NVFP4",
|
||||
"messages": [{"role": "system", "content": "..."}, {"role": "user", "content": "..."}],
|
||||
"temperature": 0,
|
||||
"max_tokens": 1536,
|
||||
"response_format": {
|
||||
"type": "json_schema",
|
||||
"json_schema": {
|
||||
"name": "adjudication_response",
|
||||
"strict": true,
|
||||
"schema": {}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The gateway validates the parsed response again locally. Wire constraints reduce malformed output; they do not replace semantic validation.
|
||||
|
||||
### B. Endpoint Registry
|
||||
|
||||
#### New tables
|
||||
|
||||
```sql
|
||||
CREATE TABLE inference_endpoints (
|
||||
id UUID PRIMARY KEY,
|
||||
name TEXT NOT NULL UNIQUE,
|
||||
protocol TEXT NOT NULL CHECK (protocol IN ('ollama_native','openai_chat','specialist_http')),
|
||||
base_url TEXT NOT NULL,
|
||||
auth_secret_ref TEXT,
|
||||
auth_scheme TEXT NOT NULL DEFAULT 'bearer',
|
||||
default_headers JSONB NOT NULL DEFAULT '{}',
|
||||
health_path TEXT,
|
||||
enabled BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
revision INTEGER NOT NULL DEFAULT 1,
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
|
||||
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
|
||||
);
|
||||
|
||||
CREATE TABLE model_deployments (
|
||||
id UUID PRIMARY KEY,
|
||||
endpoint_id UUID NOT NULL REFERENCES inference_endpoints(id),
|
||||
served_model_name TEXT NOT NULL,
|
||||
display_name TEXT NOT NULL,
|
||||
capabilities JSONB NOT NULL,
|
||||
context_window INTEGER,
|
||||
max_output_tokens INTEGER,
|
||||
quantization TEXT,
|
||||
runtime_metadata JSONB NOT NULL DEFAULT '{}',
|
||||
enabled BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
revision INTEGER NOT NULL DEFAULT 1,
|
||||
UNIQUE(endpoint_id, served_model_name)
|
||||
);
|
||||
|
||||
CREATE TABLE agent_stage_bindings (
|
||||
id UUID PRIMARY KEY,
|
||||
agent_id UUID NOT NULL REFERENCES ai_agents(id),
|
||||
stage TEXT NOT NULL,
|
||||
model_deployment_id UUID REFERENCES model_deployments(id),
|
||||
route_order INTEGER NOT NULL DEFAULT 0,
|
||||
routing_config JSONB NOT NULL DEFAULT '{}',
|
||||
is_active BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
revision INTEGER NOT NULL DEFAULT 1,
|
||||
UNIQUE(agent_id, stage, route_order)
|
||||
);
|
||||
```
|
||||
|
||||
Authentication values are not stored in these tables. `auth_secret_ref` identifies a mounted secret or environment key understood by the deployment.
|
||||
|
||||
### C. Document Segmenter
|
||||
|
||||
The segmenter replaces the 8,000-character prefix truncation.
|
||||
|
||||
#### Output
|
||||
|
||||
```python
|
||||
class DocumentChunk(BaseModel):
|
||||
chunk_id: str
|
||||
document_id: UUID
|
||||
document_type: str
|
||||
section_path: list[str]
|
||||
speaker: str | None
|
||||
start_char: int
|
||||
end_char: int
|
||||
text: str
|
||||
overlap_left: int
|
||||
overlap_right: int
|
||||
boilerplate_score: float
|
||||
```
|
||||
|
||||
Suggested initial limits:
|
||||
|
||||
| Document type | Target chunk size | Overlap | Notes |
|
||||
|---|---:|---:|---|
|
||||
| News / press release | 700-1,000 tokens | 100 tokens | Preserve paragraph boundaries. |
|
||||
| Filing | 900-1,300 tokens | 150 tokens | Preserve headings and item sections. |
|
||||
| Transcript | 700-1,000 tokens | 100 tokens | Preserve speaker turns. |
|
||||
| Macro event | 500-800 tokens | 80 tokens | Favor compact event context. |
|
||||
|
||||
The final values are benchmark parameters, not hard-coded assumptions.
|
||||
|
||||
### D. Candidate Extraction and Symbol Resolution
|
||||
|
||||
Deterministic parsers generate high-precision candidates before specialist inference:
|
||||
|
||||
- Ticker tokens and exchange-qualified symbols.
|
||||
- Currency and number expressions, including `million`, `billion`, ranges, percentages, basis points, and per-share amounts.
|
||||
- Calendar and fiscal periods.
|
||||
- Comparison cues such as `up`, `down`, `beat`, `miss`, `raised`, `cut`, `above`, and `below`.
|
||||
- Company aliases from the symbol registry.
|
||||
|
||||
GLiNER2 receives focused schemas and returns spans for entities, event classes, relations, and structured facts. The resolver merges deterministic and specialist candidates using source offsets, aliases, and local context.
|
||||
|
||||
Explicit mentions and inferred exposures are different edge types:
|
||||
|
||||
```text
|
||||
Document --explicitly_mentions--> Company
|
||||
Event --directly_affects--> Company
|
||||
Event --inferred_exposure--> Company
|
||||
Company --competes_with--> Company
|
||||
Company --supplies--> Company
|
||||
```
|
||||
|
||||
Only explicit and verified direct effects enter the primary company extraction. Inferred exposure continues through the existing interpolation/propagation architecture with separate confidence and provenance.
|
||||
|
||||
### E. Sentiment Stage
|
||||
|
||||
FinBERT is run on company-linked evidence groups rather than the entire article. Each record contains:
|
||||
|
||||
```python
|
||||
class CompanySentiment(BaseModel):
|
||||
company_id: UUID
|
||||
evidence_ids: list[UUID]
|
||||
positive_probability: float
|
||||
negative_probability: float
|
||||
neutral_probability: float
|
||||
calibration_version: str
|
||||
model_deployment_id: UUID
|
||||
```
|
||||
|
||||
Mixed sentiment is computed from multiple evidence groups and disagreement. It is not an unconstrained fourth softmax label.
|
||||
|
||||
### F. Novelty Stage
|
||||
|
||||
Novelty becomes retrieval-based:
|
||||
|
||||
1. Compute an exact/near-duplicate fingerprint of normalized content.
|
||||
2. Embed document chunks and canonical company-event representations.
|
||||
3. Search a recent window in the vector index.
|
||||
4. Calculate document novelty and event novelty from nearest-neighbor similarity, duplicate count, source timing, and event identity.
|
||||
5. Store nearest matches for explainability.
|
||||
|
||||
A compact embedding model will be selected in the evaluation harness. The implementation must keep the embedding backend replaceable and must not entangle novelty scoring with the generative endpoint.
|
||||
|
||||
### G. Confidence and Routing
|
||||
|
||||
#### Confidence features
|
||||
|
||||
- Entity span score.
|
||||
- Alias-resolution margin between first and second candidate.
|
||||
- Numeric parser validity.
|
||||
- Evidence coverage.
|
||||
- Relation score.
|
||||
- Sentiment calibration confidence.
|
||||
- Cross-stage agreement.
|
||||
- Duplicate/novelty certainty.
|
||||
- Document completeness.
|
||||
- Document type and known hard-case patterns.
|
||||
|
||||
A calibration artifact maps these features to field-level correctness probabilities. Routing uses both calibrated confidence and hard rules.
|
||||
|
||||
#### Example adjudication triggers
|
||||
|
||||
```text
|
||||
UNRESOLVED_ALIAS
|
||||
MULTIPLE_PRIMARY_COMPANIES
|
||||
CONTRADICTORY_NUMERIC_FACTS
|
||||
CONFLICTING_SENTIMENT
|
||||
IMPLIED_CAUSAL_IMPACT
|
||||
GUIDANCE_VS_CONSENSUS_REQUIRES_REASONING
|
||||
MATERIAL_FIELD_MISSING
|
||||
EVIDENCE_COVERAGE_BELOW_THRESHOLD
|
||||
CALIBRATED_CONFIDENCE_BELOW_THRESHOLD
|
||||
LONG_DOCUMENT_CROSS_CHUNK_RELATION
|
||||
```
|
||||
|
||||
The desired initial target is 60-80 percent Fast_Path coverage after calibration. This is an evaluation target, not an assumed result.
|
||||
|
||||
### H. Adjudication Packet
|
||||
|
||||
The 9B model receives only the information necessary to resolve a specific ambiguity:
|
||||
|
||||
```python
|
||||
class AdjudicationPacket(BaseModel):
|
||||
document_id: UUID
|
||||
document_type: str
|
||||
question_codes: list[str]
|
||||
candidate_companies: list[CompanyCandidate]
|
||||
candidate_events: list[EventCandidate]
|
||||
candidate_facts: list[FactCandidate]
|
||||
candidate_sentiments: list[CompanySentiment]
|
||||
evidence_spans: list[EvidenceSpan]
|
||||
relevant_chunks: list[DocumentChunk]
|
||||
required_decisions: list[str]
|
||||
```
|
||||
|
||||
The adjudicator output does not contain final novelty, confidence, impact, or horizon. It resolves candidate identity, relationship, event interpretation, and supported qualitative direction. All output is evidence-linked and revalidated.
|
||||
|
||||
### I. Impact and Horizon Model
|
||||
|
||||
This is the highest-impact stock-specific change.
|
||||
|
||||
#### Problem decomposition
|
||||
|
||||
- **Text sentiment**: What tone or directional implication is supported by the document?
|
||||
- **Event identity**: What happened?
|
||||
- **Market impact**: How has this kind of event historically affected this kind of security in this market regime?
|
||||
- **Horizon**: Over what time window did the response usually manifest or decay?
|
||||
|
||||
The current model conflates these. v3 separates them.
|
||||
|
||||
#### Features
|
||||
|
||||
- Event class probability vector.
|
||||
- Company-specific sentiment probability vector.
|
||||
- Numeric magnitude and normalized surprise when consensus or prior value exists.
|
||||
- Source credibility and historical source accuracy.
|
||||
- Novelty and duplicate count.
|
||||
- Evidence coverage and extraction uncertainty.
|
||||
- Document type.
|
||||
- Company sector, industry, market-cap bucket, liquidity, and beta.
|
||||
- Pre-event volatility, volume regime, and broad market regime.
|
||||
- Whether the event is direct, second-order, confirmed, quoted, or speculative.
|
||||
|
||||
#### Labels
|
||||
|
||||
Generate leakage-safe targets at defined event timestamps:
|
||||
|
||||
- Signed abnormal return relative to an approved benchmark.
|
||||
- Absolute abnormal move.
|
||||
- Abnormal volume.
|
||||
- Direction labels for intraday, 1d, 7d, 30d, and 90d windows.
|
||||
- Time to peak response and decay where data quality supports it.
|
||||
|
||||
#### Model family
|
||||
|
||||
Start with a deterministic event-weight baseline plus a CPU tabular learner such as gradient-boosted trees. Calibrate class probabilities out-of-time. The model artifact and feature pipeline are versioned independently.
|
||||
|
||||
The compatibility adapter may initially map expected signed magnitude to current `impact_score` and the most probable horizon to current `impact_horizon`, but richer distributions remain available to new consumers.
|
||||
|
||||
### J. V3 Storage Schema
|
||||
|
||||
Suggested logical records:
|
||||
|
||||
```python
|
||||
class EvidenceSpan(BaseModel):
|
||||
id: UUID
|
||||
document_id: UUID
|
||||
chunk_id: str
|
||||
start_char: int
|
||||
end_char: int
|
||||
text: str
|
||||
checksum: str
|
||||
|
||||
class ExtractedEntity(BaseModel):
|
||||
id: UUID
|
||||
entity_type: str
|
||||
literal_text: str
|
||||
canonical_id: UUID | None
|
||||
evidence_id: UUID
|
||||
confidence: float
|
||||
derivation: str
|
||||
|
||||
class ExtractedFact(BaseModel):
|
||||
id: UUID
|
||||
fact_type: str
|
||||
subject_entity_id: UUID | None
|
||||
predicate: str
|
||||
literal_value: str
|
||||
normalized_value: dict | None
|
||||
period: dict | None
|
||||
evidence_ids: list[UUID]
|
||||
confidence: float
|
||||
derivation: str
|
||||
|
||||
class CompanySignalCandidate(BaseModel):
|
||||
company_id: UUID
|
||||
relevance_probability: float
|
||||
event_probabilities: dict[str, float]
|
||||
sentiment_probabilities: dict[str, float]
|
||||
direction_probabilities: dict[str, float]
|
||||
horizon_probabilities: dict[str, float]
|
||||
expected_magnitude: float | None
|
||||
evidence_ids: list[UUID]
|
||||
routing_reasons: list[str]
|
||||
adjudicated: bool
|
||||
|
||||
class StageLineage(BaseModel):
|
||||
stage: str
|
||||
endpoint_id: UUID | None
|
||||
deployment_id: UUID | None
|
||||
model_version: str | None
|
||||
schema_version: str
|
||||
calibration_version: str | None
|
||||
started_at: datetime
|
||||
duration_ms: int
|
||||
status: str
|
||||
```
|
||||
|
||||
### K. Compatibility Adapter
|
||||
|
||||
The adapter creates current records without discarding v3 provenance:
|
||||
|
||||
| Current field | V3 source |
|
||||
|---|---|
|
||||
| `summary` | Deterministic template or optional 9B narrative generated from approved facts. |
|
||||
| `macro_themes` | Approved event/theme classes. |
|
||||
| `novelty_score` | Retrieval-derived event/document novelty. |
|
||||
| `confidence` | Calibrated record correctness probability. |
|
||||
| `ticker` | Canonical symbol registry resolution. |
|
||||
| `relevance` | Calibrated direct-relevance probability. |
|
||||
| `sentiment` | Company-specific calibrated distribution mapped to legacy enum. |
|
||||
| `impact_score` | Approved impact-model magnitude mapped to legacy range. |
|
||||
| `impact_horizon` | Most probable approved horizon. |
|
||||
| `catalyst_type` | Versioned event taxonomy mapping. |
|
||||
| `evidence_spans` | Exact source spans. |
|
||||
|
||||
The adapter marks `model_provider = 'hybrid'` and stores complete stage lineage separately. No provider identity is hardcoded.
|
||||
|
||||
## Deployment Design for RTX 4070 Ti SUPER Cluster
|
||||
|
||||
### GPU deployment
|
||||
|
||||
One vLLM pod remains on the RTX 4070 Ti SUPER:
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
limits:
|
||||
nvidia.com/gpu: 1
|
||||
nodeSelector:
|
||||
accelerator: rtx-4070-ti-super
|
||||
args:
|
||||
- --model
|
||||
- AxionML/Qwen3.5-9B-NVFP4
|
||||
- --served-model-name
|
||||
- stonks-adjudicator-9b
|
||||
- --max-model-len
|
||||
- "8192"
|
||||
- --max-num-seqs
|
||||
- "8"
|
||||
- --gpu-memory-utilization
|
||||
- "0.80"
|
||||
- --structured-outputs-config.backend
|
||||
- auto
|
||||
```
|
||||
|
||||
Exact flags must match the pinned vLLM version. The deployment test must verify strict schema output before promotion.
|
||||
|
||||
### CPU specialist deployment
|
||||
|
||||
```yaml
|
||||
replicas: 2
|
||||
resources:
|
||||
requests:
|
||||
cpu: "2"
|
||||
memory: 4Gi
|
||||
limits:
|
||||
cpu: "6"
|
||||
memory: 10Gi
|
||||
```
|
||||
|
||||
Initial pod contents:
|
||||
|
||||
- GLiNER2 Large.
|
||||
- FinBERT.
|
||||
- Tokenizers and deterministic parsers.
|
||||
- Optional embedding model.
|
||||
|
||||
NuExtract 1.5 Smol should run as a separate benchmark or on-demand CPU deployment so its value can be measured independently.
|
||||
|
||||
### Queue topology
|
||||
|
||||
```text
|
||||
extraction.incoming
|
||||
-> intelligence.router
|
||||
-> extraction.fast
|
||||
-> extraction.adjudication
|
||||
-> extraction.persist
|
||||
-> extraction.review
|
||||
```
|
||||
|
||||
The router owns document state transitions. Workers use leases and idempotency keys so a retry cannot create duplicate intelligence records.
|
||||
|
||||
### Concurrency
|
||||
|
||||
- Fast path: configurable worker pool, initially 4-8 concurrent documents per pod.
|
||||
- Specialist API: micro-batching bounded by maximum wait time.
|
||||
- Adjudicator: application semaphore aligned with vLLM `max-num-seqs` and measured KV-cache behavior.
|
||||
- Persistence: independent bounded pool.
|
||||
|
||||
## OpenAI-Compatible Support Details
|
||||
|
||||
### Profiles
|
||||
|
||||
| Profile | Protocol | Typical use |
|
||||
|---|---|---|
|
||||
| `ollama` | `ollama_native` | Existing Ollama endpoint. |
|
||||
| `vllm` | `openai_chat` | Backward-compatible alias using vLLM capability profile. |
|
||||
| `openai` | `openai_chat` | Hosted OpenAI endpoint with secret reference and egress policy. |
|
||||
| `openai_compatible` | `openai_chat` | Any explicitly configured compatible server. |
|
||||
| `specialist` | `specialist_http` | Typed GLiNER/FinBERT service. |
|
||||
|
||||
### Capability probes
|
||||
|
||||
A deployment activation test performs:
|
||||
|
||||
1. Health request.
|
||||
2. Model listing if supported.
|
||||
3. Minimal chat request.
|
||||
4. Strict JSON Schema request.
|
||||
5. Usage metadata check.
|
||||
6. Seed/determinism check if declared.
|
||||
7. Maximum output field compatibility check.
|
||||
|
||||
Probe results are stored with timestamp and software version. A failed capability cannot be enabled merely by selecting it in the UI.
|
||||
|
||||
### Egress and data policy
|
||||
|
||||
Endpoint profiles include data-handling classification:
|
||||
|
||||
```text
|
||||
local_private
|
||||
cluster_private
|
||||
approved_external
|
||||
forbidden_for_sensitive_docs
|
||||
```
|
||||
|
||||
External endpoints are disabled by default. Routing to an approved external endpoint requires both an active binding and a document policy permitting egress.
|
||||
|
||||
## Evaluation Strategy
|
||||
|
||||
### Gold corpus
|
||||
|
||||
Build a minimum initial corpus of 1,000 human-reviewed documents, stratified across:
|
||||
|
||||
- News, filings, transcripts, and press releases.
|
||||
- Single-company and multi-company stories.
|
||||
- Earnings beats/misses and guidance changes.
|
||||
- M&A, legal, regulatory, product, supply-chain, rating, management, and macro events.
|
||||
- Explicit facts versus implied consequences.
|
||||
- Short and long documents.
|
||||
- Duplicate and recycled stories.
|
||||
|
||||
### Compared systems
|
||||
|
||||
1. Current production path with current model and current prompt.
|
||||
2. Current 9B model with corrected temperature and strict JSON Schema.
|
||||
3. GLiNER2 + deterministic extraction.
|
||||
4. GLiNER2 + deterministic extraction + FinBERT.
|
||||
5. Optional NuExtract 1.5 Smol extraction path.
|
||||
6. Full v3 fast path.
|
||||
7. Full v3 with 9B adjudication.
|
||||
|
||||
This separation prevents architecture gains from being confused with a simple fix to the current vLLM request.
|
||||
|
||||
### Metrics
|
||||
|
||||
- Company/ticker precision, recall, F1.
|
||||
- Event macro-F1 and per-class F1.
|
||||
- Numeric exact match with tolerance-aware normalization.
|
||||
- Relation F1.
|
||||
- Evidence support and offset validity.
|
||||
- Company-specific sentiment macro-F1.
|
||||
- Confidence ECE and Brier score.
|
||||
- Unsupported-claim rate.
|
||||
- JSON/schema failure rate.
|
||||
- Fast-path coverage.
|
||||
- Adjudication reason distribution.
|
||||
- p50/p95 latency and documents per minute.
|
||||
- CPU-seconds, GPU-seconds, tokens, and peak GPU memory per document.
|
||||
- Impact-model direction accuracy, calibration, rank correlation, and out-of-time error by horizon.
|
||||
|
||||
### Promotion sequence
|
||||
|
||||
1. Correct current vLLM schema constraints and temperature; establish baseline.
|
||||
2. Run v3 offline replay.
|
||||
3. Run v3 shadow mode.
|
||||
4. Enable v3 for audit-only UI.
|
||||
5. Canary compatibility outputs for a small percentage of non-trading downstream traffic.
|
||||
6. Canary signal influence with automatic rollback.
|
||||
7. Promote by document type and confidence tier.
|
||||
8. Retire v2 only after a separately reviewed milestone.
|
||||
|
||||
## Security Design
|
||||
|
||||
### Immediate blocker
|
||||
|
||||
The repository contains plaintext production-like credentials in a tracked Helm values file. Treat them as compromised:
|
||||
|
||||
1. Rotate the database, object-store, Redis, broker, and market-data credentials.
|
||||
2. Disable or replace old keys.
|
||||
3. Remove secret values from tracked files.
|
||||
4. Purge historical values using an approved Git history rewrite process.
|
||||
5. Migrate to an external secret manager.
|
||||
6. Add secret scanning to local hooks and CI.
|
||||
7. Audit access logs for the affected credentials.
|
||||
|
||||
No values are reproduced in this specification.
|
||||
|
||||
### Inference security
|
||||
|
||||
- Secrets are resolved only at runtime.
|
||||
- Request logging records hashes and metadata, not authorization values.
|
||||
- Raw source text is not logged at INFO level.
|
||||
- External endpoint use is policy-gated.
|
||||
- Stored raw prompts and responses use restricted object-store buckets and retention policies.
|
||||
- Provider errors are normalized to avoid echoing secret-bearing response headers.
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Unit tests
|
||||
|
||||
- Endpoint capability selection.
|
||||
- Strict schema payload construction.
|
||||
- Header and error redaction.
|
||||
- Segment offset round trips.
|
||||
- Numeric normalization.
|
||||
- Alias resolution and ambiguity margins.
|
||||
- Evidence linkage.
|
||||
- Compatibility mappings.
|
||||
- Confidence feature construction.
|
||||
- Routing rules.
|
||||
|
||||
### Property-based tests
|
||||
|
||||
- Every Evidence_Span round-trips to identical source text.
|
||||
- Normalization never changes the literal stored value.
|
||||
- Unknown providers always fail closed.
|
||||
- Credentials never appear in serialized errors or logs.
|
||||
- Compatibility mappings remain bounded in legacy field ranges.
|
||||
- Reprocessing the same document and model versions is idempotent.
|
||||
- Route decisions are deterministic for identical calibrated inputs.
|
||||
|
||||
### Contract tests
|
||||
|
||||
- Ollama native endpoint.
|
||||
- vLLM OpenAI-compatible endpoint.
|
||||
- Mock hosted OpenAI-compatible endpoint.
|
||||
- Specialist service schemas.
|
||||
- Capability probe behavior across supported structured-output modes.
|
||||
|
||||
### Integration tests
|
||||
|
||||
- Full document through fast path.
|
||||
- Full document through adjudication path.
|
||||
- Adjudicator outage with safe fast-path handling.
|
||||
- Long filing crossing multiple chunks.
|
||||
- Multi-company article with opposing sentiment.
|
||||
- Duplicate story and novelty calculation.
|
||||
- Rollback from v3 to v2.
|
||||
|
||||
### Load tests
|
||||
|
||||
- CPU specialist batching.
|
||||
- Queue backpressure.
|
||||
- vLLM concurrent adjudication.
|
||||
- Peak 4070 Ti SUPER memory.
|
||||
- End-to-end throughput at representative article arrival rates.
|
||||
|
||||
## Migration Plan
|
||||
|
||||
### Phase 0: Security and baseline
|
||||
|
||||
Rotate secrets, add scanning, pin current runtime configuration, and benchmark the existing path.
|
||||
|
||||
### Phase 1: Provider foundation
|
||||
|
||||
Add the Inference Gateway and registry. Convert current extractor, classifier, and thesis rewriter. Keep behavior otherwise equivalent.
|
||||
|
||||
### Phase 2: Correct current generative extraction
|
||||
|
||||
Use strict schema-constrained vLLM output, temperature zero, accurate provider lineage, and bounded output sizes. This produces a fair current baseline.
|
||||
|
||||
### Phase 3: V3 data and specialist shadow path
|
||||
|
||||
Add segmentation, v3 storage, deterministic extraction, GLiNER2, FinBERT, novelty, confidence, and audit UI. Persist shadow outputs only.
|
||||
|
||||
### Phase 4: Adjudication and impact model
|
||||
|
||||
Add confidence routing, focused 9B adjudication, historical outcome features, deterministic impact baseline, and trained impact model.
|
||||
|
||||
### Phase 5: Canary and promotion
|
||||
|
||||
Enable compatibility outputs by percentage and document type, then gradually allow v3 signals into aggregation.
|
||||
|
||||
### Phase 6: Fine-tuning and cleanup
|
||||
|
||||
Fine-tune specialist models from reviewed cases, increase fast-path coverage, then remove deprecated v2 code in a separate change.
|
||||
|
||||
## Risks and Mitigations
|
||||
|
||||
| Risk | Mitigation |
|
||||
|---|---|
|
||||
| Specialist model misses implicit meaning. | Retain 9B adjudication with calibrated routing. |
|
||||
| Complexity creates more failure modes. | Typed stage contracts, idempotent queues, stage-level metrics, and safe fallback. |
|
||||
| Fast-path confidence is overestimated. | Held-out calibration, conservative thresholds, and shadow review. |
|
||||
| Impact model learns leakage or regime artifacts. | Event-time feature snapshots, out-of-time validation, per-regime monitoring, and immutable predictions. |
|
||||
| OpenAI-compatible servers differ subtly. | Capability probes and profile-specific wire settings, not optimistic assumptions. |
|
||||
| A second model increases memory. | Keep specialists on CPU and make NuExtract optional/on-demand. |
|
||||
| Existing downstream code assumes one model output. | Compatibility adapter and additive migrations. |
|
||||
| Reviewer labels become inconsistent. | Annotation guide, double review for hard cases, and inter-annotator agreement tracking. |
|
||||
@@ -0,0 +1,314 @@
|
||||
# Requirements Document
|
||||
|
||||
## Introduction
|
||||
|
||||
Stonks Oracle currently asks a general-purpose generative model to perform entity discovery, ticker attribution, fact extraction, event classification, sentiment analysis, novelty estimation, confidence estimation, impact scoring, horizon selection, evidence quoting, and summarization in one response. That design is convenient, but it couples factual extraction to generative sampling and allows uncalibrated model self-assessments to influence signal weighting.
|
||||
|
||||
This specification introduces **Intelligence Pipeline v3**, a multi-stage, evidence-grounded inference system that preserves the current 9B model's reasoning ability for genuinely ambiguous documents while moving routine extraction, sentiment, novelty, confidence, and impact estimation into specialized and calibratable components. The target deployment retains the existing RTX 4070 Ti SUPER vLLM footprint and uses CPU-first specialist services for the fast path.
|
||||
|
||||
The specification also replaces provider-specific branching with a capability-aware inference gateway supporting Ollama native endpoints and generic OpenAI-compatible endpoints, including vLLM and hosted OpenAI-compatible services.
|
||||
|
||||
## Goals
|
||||
|
||||
1. Match or exceed the current 9B pipeline's field-level accuracy and reasoning ceiling.
|
||||
2. Reduce average GPU work per document without increasing peak GPU memory materially.
|
||||
3. Make every extracted fact traceable to evidence in the source document.
|
||||
4. Replace model-generated confidence, novelty, impact, and horizon values with calibrated or deterministic values.
|
||||
5. Support generic OpenAI-compatible inference without adding another duplicated provider branch.
|
||||
6. Establish a measurable benchmark, shadow rollout, and promotion process.
|
||||
7. Preserve downstream compatibility while the v2 schema and database consumers are migrated.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
1. Replacing the existing recommendation, risk, or trading engines in one release.
|
||||
2. Removing the current 9B model before the v3 pipeline passes promotion gates.
|
||||
3. Treating backtest profit alone as proof of extraction correctness.
|
||||
4. Sending credentials or proprietary documents to external providers by default.
|
||||
5. Requiring a second GPU-resident generative model.
|
||||
|
||||
## Glossary
|
||||
|
||||
- **Inference_Gateway**: Shared client and routing layer that invokes Ollama-native, OpenAI-compatible, and specialist inference endpoints through one typed interface.
|
||||
- **Endpoint_Profile**: Persisted endpoint configuration containing protocol, URL, authentication reference, capabilities, and health settings.
|
||||
- **Model_Deployment**: A model served by an Endpoint_Profile with declared capabilities and limits.
|
||||
- **Pipeline_Stage**: One step in Intelligence Pipeline v3, such as segmentation, extraction, sentiment, verification, novelty, adjudication, or impact prediction.
|
||||
- **Fast_Path**: CPU-first processing that completes without invoking the 9B generative model.
|
||||
- **Adjudication_Path**: Processing that invokes the 9B model because evidence is ambiguous, contradictory, incomplete, or semantically complex.
|
||||
- **Evidence_Span**: Exact source text plus stable character offsets and a chunk identifier.
|
||||
- **Candidate**: A proposed entity, fact, event, sentiment, or relation before validation and calibration.
|
||||
- **Calibrated_Confidence**: Probability-like confidence derived from validation data, not a number supplied by a generative model.
|
||||
- **Impact_Model**: A lightweight supervised model that estimates signed market impact and horizon from extracted features and historical outcomes.
|
||||
- **Compatibility_Adapter**: Mapper from v3 records to the current v2 `document_intelligence` and `document_impact_records` structures.
|
||||
- **Gold_Corpus**: Human-reviewed documents and field-level labels used for acceptance testing.
|
||||
- **Shadow_Mode**: Running v3 alongside the current pipeline without allowing v3 outputs to affect production decisions.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement 1: Secure Baseline and Credential Remediation
|
||||
|
||||
**User Story:** As an operator, I want repository and deployment credentials handled through secret stores, so that model-pipeline improvements do not ship on top of exposed credentials.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Team SHALL rotate every credential currently stored as plaintext in tracked repository files before deploying Intelligence Pipeline v3.
|
||||
2. THE Repository SHALL remove plaintext database, object-store, Redis, broker, and market-data credentials from tracked Helm values and Git history.
|
||||
3. THE Deployment SHALL reference credentials through Kubernetes Secrets populated by External Secrets, SOPS, Sealed Secrets, or an equivalent approved mechanism.
|
||||
4. THE CI_Pipeline SHALL run secret scanning on pull requests and protected branches.
|
||||
5. IF secret scanning detects a high-confidence credential, THEN THE CI_Pipeline SHALL fail before packaging or deployment.
|
||||
6. THE Documentation SHALL record the rotation date and affected secret names without recording secret values.
|
||||
|
||||
### Requirement 2: Capability-Aware Generic Inference Gateway
|
||||
|
||||
**User Story:** As a developer, I want one inference abstraction that supports Ollama and generic OpenAI-compatible services, so that endpoints can be changed without duplicating business logic.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Inference_Gateway SHALL support the protocols `ollama_native`, `openai_chat`, and `specialist_http`.
|
||||
2. THE Inference_Gateway SHALL treat `vllm` as a backward-compatible profile alias for `openai_chat`, not as a separate client implementation.
|
||||
3. WHEN an `openai_chat` request requires structured output and the endpoint declares `json_schema` support, THE Inference_Gateway SHALL send the complete supplied JSON Schema in strict structured-output mode.
|
||||
4. WHEN an endpoint supports only JSON-object mode, THE Inference_Gateway SHALL use JSON-object mode only when that fallback is explicitly enabled for the Model_Deployment.
|
||||
5. WHEN neither schema nor JSON-object constraints are supported, THE Inference_Gateway SHALL use prompt-only JSON generation only when explicitly enabled and SHALL mark the response as unconstrained.
|
||||
6. IF a provider or protocol value is unknown, THEN THE Inference_Gateway SHALL fail closed with a configuration error and SHALL NOT silently route to Ollama.
|
||||
7. THE Inference_Gateway SHALL support configurable base URL, request path, API-key secret reference, authorization scheme, additional headers, timeouts, retries, concurrency limit, and provider-specific extra request fields.
|
||||
8. THE Inference_Gateway SHALL redact authentication values and configured sensitive headers from logs, traces, and stored request snapshots.
|
||||
9. THE Inference_Gateway SHALL expose typed response metadata including endpoint ID, deployment ID, model name, protocol, request ID, latency, token usage, structured-output mode, retry count, and error category.
|
||||
10. THE Inference_Gateway SHALL provide health and capability probes and cache their results with a bounded TTL.
|
||||
11. WHEN endpoint capabilities are changed or a probe fails, THE Router SHALL invalidate the cached capability record before the next invocation.
|
||||
12. THE Existing thesis rewriter, event classifier, and document extractor SHALL use the same Inference_Gateway rather than implementing separate Ollama/vLLM branches.
|
||||
|
||||
### Requirement 3: Canonical Endpoint and Model Registry
|
||||
|
||||
**User Story:** As an operator, I want the database and UI to identify exactly which endpoint and model serve each stage, so that environment, migration, Helm, and runtime defaults cannot drift silently.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Database SHALL store `inference_endpoints`, `model_deployments`, and `agent_stage_bindings` as canonical runtime records.
|
||||
2. EACH Inference_Endpoint SHALL include name, protocol, base URL, authentication secret reference, health path, default headers, enabled state, and timestamps.
|
||||
3. EACH Model_Deployment SHALL include endpoint ID, served model name, display name, capabilities, context limit, output limit, quantization, structured-output modes, and enabled state.
|
||||
4. EACH Agent_Stage_Binding SHALL map an agent and pipeline stage to one or more ordered Model_Deployments plus routing configuration.
|
||||
5. WHEN runtime configuration is resolved, THE Service SHALL record the exact endpoint, deployment, and binding revision used.
|
||||
6. THE API SHALL validate endpoint URLs, protocol values, capability declarations, and model names before activation.
|
||||
7. THE UI SHALL use controlled protocol and endpoint selections rather than an unrestricted provider text field.
|
||||
8. THE Migration SHALL translate existing `ollama` and `vllm` agent settings into Endpoint_Profile and Model_Deployment records without breaking active agents.
|
||||
9. THE Application SHALL have one documented fallback configuration source; conflicting model defaults in code, migrations, and Helm SHALL be removed.
|
||||
|
||||
### Requirement 4: Document Segmentation and Source Preservation
|
||||
|
||||
**User Story:** As an analyst, I want long articles, filings, and transcripts processed without destructive truncation, so that material facts near the end of a document are not lost.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Pipeline SHALL preserve the full normalized source document and SHALL NOT truncate it to a fixed character prefix for extraction.
|
||||
2. THE Segmenter SHALL create sentence-aware chunks with stable chunk IDs, source character offsets, and configurable overlap.
|
||||
3. THE Segmenter SHALL use document-type-specific chunk sizes for articles, filings, transcripts, and press releases.
|
||||
4. THE Segmenter SHALL preserve headings, speaker labels, table-derived text markers, and section boundaries when present.
|
||||
5. WHEN duplicate or boilerplate sections are detected, THE Segmenter SHALL mark them without deleting the only occurrence of a fact.
|
||||
6. THE Pipeline SHALL retain a mapping from every downstream Evidence_Span to the original document offsets.
|
||||
7. IF a document cannot be decoded or segmented, THEN THE Pipeline SHALL mark the document as a typed preprocessing failure and SHALL NOT fabricate an empty extraction.
|
||||
|
||||
### Requirement 5: Deterministic Candidate Generation and Ticker Resolution
|
||||
|
||||
**User Story:** As a signal consumer, I want explicit companies and numeric facts resolved deterministically where possible, so that a language model is not asked to invent identifiers or parse trivial values.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Candidate_Generator SHALL detect explicit ticker symbols, company names, aliases, executives, products, currencies, percentages, dates, ranges, EPS values, revenue values, guidance values, and common financial ratios.
|
||||
2. THE Symbol_Resolver SHALL use the existing company and symbol registry as the source of truth for ticker identity.
|
||||
3. THE Pipeline SHALL distinguish explicit company mentions from inferred exposure relationships.
|
||||
4. THE Pipeline SHALL NOT pass the entire tracked-ticker universe to a generative prompt.
|
||||
5. WHEN multiple companies match an alias, THE Symbol_Resolver SHALL return ranked candidates and SHALL require contextual disambiguation or adjudication.
|
||||
6. WHEN a ticker is not present in the symbol registry, THE Pipeline SHALL preserve the literal mention as unresolved rather than inventing a registered ticker.
|
||||
7. THE Numeric_Normalizer SHALL retain both literal source text and normalized values, currencies, units, periods, and ranges.
|
||||
8. THE Pipeline SHALL reject normalized numeric facts whose value cannot be traced to an Evidence_Span.
|
||||
|
||||
### Requirement 6: Specialist Extraction Service
|
||||
|
||||
**User Story:** As an operator, I want routine entity, event, relation, and fact extraction to run on CPU-first specialist models, so that GPU capacity is reserved for difficult reasoning.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Specialist_Service SHALL expose batched APIs for entity extraction, schema extraction, relation extraction, and text classification.
|
||||
2. THE Initial specialist extractor SHALL support company, person, product, event, financial metric, date, percentage, currency, and relationship schemas.
|
||||
3. THE Specialist_Service SHALL return character spans and per-candidate scores for every extracted item.
|
||||
4. THE Specialist_Service SHALL run without requiring the RTX 4070 Ti SUPER.
|
||||
5. THE Initial deployment SHALL evaluate GLiNER2 Large as the primary unified extraction and classification model.
|
||||
6. THE Benchmark SHALL evaluate NuExtract 1.5 Smol as an optional long-form or hierarchical fact-extraction stage, but it SHALL NOT become an always-resident GPU model without passing incremental-value and resource gates.
|
||||
7. THE Specialist_Service SHALL support model version pinning, warm-up, health checks, bounded batching, and graceful degradation.
|
||||
8. WHEN specialist inference fails, THE Router SHALL either retry according to policy or route to adjudication; it SHALL record the failure and SHALL NOT silently substitute default facts.
|
||||
9. THE Specialist_Service SHALL expose model and schema versions in every response.
|
||||
|
||||
### Requirement 7: Company-Specific Financial Sentiment
|
||||
|
||||
**User Story:** As an analyst, I want sentiment tied to each company and supporting evidence, so that a positive statement about one firm is not applied to every company in the article.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Sentiment_Stage SHALL score evidence sentences or evidence groups associated with each resolved company.
|
||||
2. THE Initial sentiment classifier SHALL evaluate FinBERT as the baseline financial-domain model.
|
||||
3. THE Sentiment_Stage SHALL return positive, negative, and neutral probabilities rather than only a discrete label.
|
||||
4. THE Pipeline SHALL derive mixed sentiment from conflicting supported evidence, not from an unconstrained model label.
|
||||
5. WHEN an article mentions competitors with opposing effects, THE Pipeline SHALL produce separate company-specific sentiment records.
|
||||
6. THE Sentiment_Stage SHALL preserve the evidence IDs used for each probability distribution.
|
||||
7. THE Production model SHALL be calibrated on the Gold_Corpus before its probabilities are treated as confidence values.
|
||||
|
||||
### Requirement 8: Evidence Verification and Grounding
|
||||
|
||||
**User Story:** As an auditor, I want every material claim verified against source evidence, so that generated summaries and signals cannot rely on unsupported assertions.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. EVERY material company fact, event, amount, direction, and relationship SHALL reference one or more Evidence_Spans.
|
||||
2. THE Verifier SHALL check span validity, source offsets, entity association, and schema compatibility.
|
||||
3. THE Benchmark SHALL evaluate a compact entailment verifier for claims that require semantic validation beyond exact matching.
|
||||
4. IF a candidate conflicts with its evidence, THEN THE Pipeline SHALL reject it or route the conflict to adjudication.
|
||||
5. THE Pipeline SHALL calculate evidence coverage as the proportion of required fields supported by valid spans.
|
||||
6. THE Pipeline SHALL store rejected candidates and rejection reasons for audit and active learning.
|
||||
7. JSON repair SHALL NOT transform an unsupported or truncated generative answer into a valid production extraction without marking it as repaired and revalidating every material field.
|
||||
|
||||
### Requirement 9: Deterministic Novelty and Duplicate Detection
|
||||
|
||||
**User Story:** As a signal consumer, I want novelty based on comparison with recent information, so that a model's subjective novelty guess does not amplify repeated news.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Novelty_Stage SHALL compare each document and material event against a configurable recent-history window.
|
||||
2. THE Novelty_Stage SHALL combine exact/near-duplicate fingerprints with compact semantic embeddings.
|
||||
3. THE Pipeline SHALL calculate novelty separately for document-level content and company-event content.
|
||||
4. THE Novelty_Stage SHALL return nearest matching document or event IDs plus similarity scores.
|
||||
5. THE Pipeline SHALL derive `novelty_score` from the similarity distribution and duplicate count using a versioned deterministic formula or calibrated model.
|
||||
6. A generative model SHALL NOT provide the authoritative novelty value used by aggregation.
|
||||
7. WHEN novelty cannot be calculated because history is unavailable, THE Pipeline SHALL use a conservative versioned default and mark the reason.
|
||||
|
||||
### Requirement 10: Calibrated Extraction Confidence
|
||||
|
||||
**User Story:** As a downstream scorer, I want confidence to reflect observed correctness, so that the system does not trust a model merely because it reports confidence in itself.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Pipeline SHALL calculate field-level and record-level confidence from specialist scores, symbol resolution, evidence validation, schema completeness, model agreement, and historical calibration.
|
||||
2. A generative model's self-reported confidence SHALL NOT be used as authoritative extraction confidence.
|
||||
3. THE Calibration_Process SHALL evaluate isotonic, Platt, or equivalent calibration methods on held-out Gold_Corpus data.
|
||||
4. THE Pipeline SHALL report Expected Calibration Error and Brier score for probability-bearing stages.
|
||||
5. THE Router SHALL use calibrated uncertainty and explicit conflict rules to choose Fast_Path or Adjudication_Path.
|
||||
6. THE Pipeline SHALL retain stage-level confidence components for explainability.
|
||||
7. WHEN calibration data is insufficient for a class, THE Pipeline SHALL use conservative thresholds and mark the class as under-calibrated.
|
||||
|
||||
### Requirement 11: 9B Generative Adjudicator
|
||||
|
||||
**User Story:** As an analyst, I want the current reasoning capability retained for hard documents, so that specialization does not reduce intelligence on nuanced cases.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Adjudicator SHALL initially use the existing 9B-class model served by vLLM on the RTX 4070 Ti SUPER.
|
||||
2. THE Adjudicator SHALL receive selected source chunks, Evidence_Spans, candidate facts, candidate probabilities, conflicts, and a precise adjudication question rather than the entire tracked ticker list.
|
||||
3. THE Adjudicator SHALL use strict JSON Schema constrained output when supported by the endpoint.
|
||||
4. THE Adjudicator SHALL use deterministic generation settings appropriate for extraction, including a production default temperature of zero unless a benchmark proves a different value superior.
|
||||
5. THE Adjudicator SHALL NOT be asked to provide authoritative novelty, confidence, or impact values.
|
||||
6. THE Router SHALL invoke adjudication for unresolved entity aliases, contradictory evidence, multi-company causal relationships, implied consequences, complex guidance, materially incomplete fast-path results, or low calibrated confidence.
|
||||
7. THE Adjudicator SHALL return field-level decisions, evidence references, and decision reasons.
|
||||
8. IF adjudication output references evidence not supplied to it, THEN THE Verifier SHALL reject the unsupported field.
|
||||
9. THE Adjudicator SHALL remain optional for thesis prose; deterministic signal records SHALL not depend on prose generation succeeding.
|
||||
10. THE Peak GPU memory budget SHALL not exceed the measured current 9B deployment baseline by more than 5 percent unless explicitly approved.
|
||||
|
||||
### Requirement 12: Stock-Specific Impact and Horizon Model
|
||||
|
||||
**User Story:** As a trader, I want impact and horizon estimated from historical market behavior rather than language-model intuition, so that signals are tied to observed outcomes.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Pipeline SHALL separate textual sentiment from expected market impact.
|
||||
2. THE Impact_Model SHALL consume versioned features including event type probabilities, sentiment probabilities, magnitude, surprise where available, source history, novelty, company attributes, market regime, pre-event volatility, and evidence quality.
|
||||
3. THE Training_Pipeline SHALL create leakage-safe labels from abnormal returns and volume responses over configured horizons.
|
||||
4. THE Initial model family SHALL be a CPU-efficient calibrated tabular model and SHALL include a transparent deterministic baseline.
|
||||
5. THE Impact_Model SHALL output signed direction probabilities, expected magnitude, horizon probabilities, and model uncertainty.
|
||||
6. THE Production model SHALL be evaluated out-of-time and by event type, sector, market-cap bucket, and source.
|
||||
7. THE Pipeline SHALL preserve existing downstream fields through a Compatibility_Adapter while storing richer probability distributions in v3 tables.
|
||||
8. IF no trained Impact_Model is approved, THEN THE Pipeline SHALL use the deterministic baseline and SHALL NOT fall back to a generative model's impact score.
|
||||
9. THE Outcome_Evaluator SHALL feed realized outcomes back into model monitoring and retraining datasets without mutating historical predictions.
|
||||
10. THE Pipeline SHALL version feature definitions, training data ranges, model artifacts, thresholds, and calibration artifacts.
|
||||
|
||||
### Requirement 13: Versioned Intelligence Schema and Provenance
|
||||
|
||||
**User Story:** As a developer, I want a richer schema with field-level provenance, so that downstream consumers can distinguish facts, probabilities, decisions, and generated prose.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Database SHALL store v3 entities, facts, evidence spans, company signal candidates, stage runs, adjudication decisions, and model lineage in normalized or well-defined JSONB-backed tables.
|
||||
2. EVERY v3 field SHALL identify whether it is deterministic, specialist-derived, adjudicated, calibrated, or compatibility-derived.
|
||||
3. EVERY stage run SHALL record input references, output references, model versions, endpoint identity, duration, error state, and trace ID.
|
||||
4. THE Compatibility_Adapter SHALL map approved v3 outputs to existing v2 persistence records during migration.
|
||||
5. THE Compatibility_Adapter SHALL identify its own version and SHALL not overwrite original v3 probabilities.
|
||||
6. THE persisted `model_provider` and model lineage SHALL reflect the actual route used and SHALL not be hardcoded to Ollama.
|
||||
7. THE Pipeline SHALL retain raw model output only in approved object storage with configured retention and access controls.
|
||||
|
||||
### Requirement 14: Parallelism, Queues, and Resource Isolation
|
||||
|
||||
**User Story:** As an operator, I want parallel throughput without saturating the GPU or blocking unrelated stages, so that the cluster remains responsive.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Extractor SHALL support multiple in-flight documents using bounded asynchronous workers rather than a single unbounded sequential loop.
|
||||
2. THE Fast_Path and Adjudication_Path SHALL have separate queue or concurrency controls.
|
||||
3. THE Specialist_Service SHALL support dynamic batching within configured latency limits.
|
||||
4. THE Adjudicator SHALL enforce a GPU-safe concurrency semaphore coordinated with vLLM limits.
|
||||
5. THE Router SHALL apply backpressure when either path exceeds its queue-depth or latency thresholds.
|
||||
6. THE Deployment SHALL assign specialist workloads to CPU nodes and the 9B vLLM workload to the RTX 4070 Ti SUPER node by default.
|
||||
7. THE System SHALL expose queue depth, service time, batch size, GPU memory, GPU utilization, fast-path rate, and adjudication rate.
|
||||
8. WHEN the adjudicator is unavailable, THE Pipeline SHALL continue only for documents meeting a conservative fast-path acceptance threshold; all others SHALL remain queued or fail safely.
|
||||
|
||||
### Requirement 15: Observability, Audit, and Explainability
|
||||
|
||||
**User Story:** As an operator and analyst, I want to understand why a document produced a signal and which component made each decision.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Pipeline SHALL emit one distributed trace covering preprocessing, specialist stages, routing, adjudication, impact prediction, and persistence.
|
||||
2. THE Metrics SHALL include field validity, evidence coverage, entity resolution rate, sentiment agreement, calibration metrics, fast-path coverage, adjudication causes, schema failure rate, latency percentiles, token usage, and GPU-seconds per document.
|
||||
3. THE Audit API SHALL return model lineage and evidence for a document, company, and generated signal.
|
||||
4. THE UI SHALL distinguish observed facts, inferred exposure, sentiment, predicted impact, and generated narrative.
|
||||
5. THE Pipeline SHALL store routing reasons as structured codes rather than log-only text.
|
||||
6. THE Pipeline SHALL allow a reviewer to mark a field correct, incorrect, unsupported, or ambiguous and add a corrected value.
|
||||
7. Reviewer corrections SHALL be immutable audit events and SHALL feed the active-learning dataset only through an approved export process.
|
||||
|
||||
### Requirement 16: Benchmark, Shadow Mode, and Promotion Gates
|
||||
|
||||
**User Story:** As an owner, I want the new architecture proven against the current system before it affects trades, so that complexity is justified by measured improvement.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Team SHALL create a versioned Gold_Corpus covering articles, filings, press releases, transcripts, macro news, multi-company stories, contradictory reports, and long documents.
|
||||
2. THE Evaluation_Harness SHALL run the current pipeline and every proposed v3 configuration on identical inputs.
|
||||
3. THE Evaluation SHALL report field precision, recall, F1, exact-match accuracy, evidence support rate, ticker-resolution accuracy, event macro-F1, sentiment macro-F1, calibration, latency, throughput, CPU use, GPU use, and cost.
|
||||
4. THE Evaluation SHALL report results by document type, event class, source, sector, and difficulty bucket.
|
||||
5. THE Initial promotion gate SHALL require no statistically meaningful regression in any safety-critical field and measurable improvement in at least one of evidence support, calibration, schema validity, or resource efficiency.
|
||||
6. THE Initial production target SHALL achieve at least 60 percent Fast_Path coverage on the representative corpus while meeting accuracy gates.
|
||||
7. THE GPU-seconds per accepted document SHALL improve by at least 2x relative to the current 9B-every-document baseline before full promotion.
|
||||
8. THE v3 pipeline SHALL run in Shadow_Mode for a configurable period and minimum document count before it may influence aggregation.
|
||||
9. THE Promotion process SHALL support canary percentages, automatic rollback thresholds, and one-click reversion to the current pipeline.
|
||||
10. Backtest or paper-trading performance SHALL be reported separately from extraction correctness and SHALL not override failed correctness gates.
|
||||
|
||||
### Requirement 17: Active Learning and Specialist Fine-Tuning
|
||||
|
||||
**User Story:** As a model owner, I want difficult and corrected examples to improve the specialist path over time, so that fewer documents require the 9B adjudicator.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Active_Learning_Exporter SHALL select low-confidence, conflicting, adjudicated, and reviewer-corrected examples without exporting secrets or unauthorized content.
|
||||
2. THE Export format SHALL retain source text, spans, schema labels, relations, adjudicator decisions, reviewer corrections, and provenance.
|
||||
3. THE Training_Pipeline SHALL support fine-tuning the selected specialist extractor on the Stonks Oracle schema.
|
||||
4. EACH trained artifact SHALL be evaluated against a frozen holdout and the current production artifact.
|
||||
5. A specialist model SHALL not be promoted solely because it reduces adjudication rate; it SHALL also pass field-level correctness and calibration gates.
|
||||
6. THE Registry SHALL retain model cards containing training range, dataset version, intended use, limitations, and evaluation results.
|
||||
|
||||
### Requirement 18: Backward-Compatible Rollout
|
||||
|
||||
**User Story:** As a maintainer, I want to ship the new pipeline incrementally, so that existing APIs and downstream services continue operating during migration.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Current v2 extractor SHALL remain available behind a feature flag until v3 completes shadow and canary promotion.
|
||||
2. THE Compatibility_Adapter SHALL produce the fields required by aggregation, recommendation, validation, reporting, and API consumers.
|
||||
3. THE Database migration SHALL be additive before any destructive column or table change.
|
||||
4. THE Deployment SHALL permit per-agent, per-document-type, and percentage-based routing between v2 and v3.
|
||||
5. WHEN rollback is triggered, THE System SHALL route new work to v2 without deleting v3 audit data.
|
||||
6. THE Team SHALL remove deprecated provider branches, v2 prompt logic, and compatibility mappings only in a separately approved cleanup milestone.
|
||||
@@ -0,0 +1,427 @@
|
||||
# Implementation Plan: Intelligence Pipeline v3
|
||||
|
||||
## Overview
|
||||
|
||||
Replace the monolithic 9B model extraction pipeline with a staged, evidence-grounded multi-component architecture. CPU-first specialist services handle routine extraction, sentiment, novelty, and calibration while the existing 9B vLLM model is preserved for semantic adjudication of ambiguous cases. A capability-aware inference gateway replaces duplicated provider branches, a stock-specific impact model replaces generative self-scores, and a full shadow/canary promotion process ensures measured improvement before production influence.
|
||||
|
||||
## Tasks
|
||||
|
||||
- [x] 1. Rotate exposed credentials
|
||||
- [x] 1.1 Identify every live or reusable credential in `infra/helm/stonks-oracle/values-live-math.yaml` and any other tracked files
|
||||
- [x] 1.2 Rotate database, MinIO/object-store, Redis, broker, and market-data credentials
|
||||
- [x] 1.3 Disable the replaced keys and review relevant access logs
|
||||
- [x] 1.4 Remove plaintext values from the working tree without copying them into issues, PRs, logs, or spec comments
|
||||
- [x] 1.5 Purge the values from Git history using an approved coordinated history rewrite
|
||||
- [x] 1.6 Verify that old credentials no longer authenticate
|
||||
- _Requirements: 1.1, 1.2, 1.6_
|
||||
|
||||
- [x] 2. Add managed secret delivery
|
||||
- [x] 2.1 Select External Secrets, SOPS, Sealed Secrets, or the cluster-standard mechanism
|
||||
- [x] 2.2 Replace Helm secret values with secret references
|
||||
- [x] 2.3 Document bootstrap and rotation procedures
|
||||
- [x] 2.4 Add a deployment test proving pods receive required keys without values appearing in rendered manifests
|
||||
- _Requirements: 1.3, 1.6_
|
||||
|
||||
- [x] 3. Add repository secret scanning
|
||||
- [x] 3.1 Add a secret scanner to pre-commit or Kiro hooks
|
||||
- [x] 3.2 Add the scanner to pull-request and protected-branch CI
|
||||
- [x] 3.3 Add tests/fixtures that prove real-looking secrets fail and explicit safe fixtures pass
|
||||
- _Requirements: 1.4, 1.5_
|
||||
|
||||
- [x] 4. Establish the current runtime source of truth
|
||||
- [x] 4.1 Inventory active cluster deployments, agent database records, Helm releases, and environment variables
|
||||
- [x] 4.2 Record the actual model, quantization, vLLM version, max model length, max sequences, GPU utilization limit, and current provider for every agent
|
||||
- [x] 4.3 Resolve the conflicting Qwen/NuExtract defaults in code and infrastructure for the baseline branch
|
||||
- [x] 4.4 Produce `docs/intelligence-pipeline-v3/current-runtime-baseline.md` without credentials
|
||||
- _Requirements: 3.9_
|
||||
|
||||
- [x] 5. Build a baseline replay command
|
||||
- [x] 5.1 Add a CLI that replays a fixed document set through the current pipeline without writing trading outputs
|
||||
- [x] 5.2 Capture structured output, schema validity, retries, duration, token usage, GPU metrics, provider/model lineage, and current downstream mappings
|
||||
- [x] 5.3 Pin all baseline configuration and random seeds that the provider supports
|
||||
- [x] 5.4 Store baseline reports under a versioned artifact path
|
||||
- _Requirements: 16.2, 16.3_
|
||||
|
||||
- [x] 6. Define the v3 annotation schema
|
||||
- [x] 6.1 Define labels for entities, canonical companies, events, relations, numeric facts, periods, sentiment, evidence spans, direct effects, inferred exposure, and ambiguity
|
||||
- [x] 6.2 Define evidence and adjudication guidelines with positive and negative examples
|
||||
- [x] 6.3 Define which fields are safety-critical for promotion gates
|
||||
- [x] 6.4 Add schema validators and sample annotations
|
||||
- _Requirements: 16.1, 16.4_
|
||||
|
||||
- [x] 7. Create the first Gold Corpus
|
||||
- [x] 7.1 Sample at least 1,000 documents stratified by type, event class, length, source, company count, and difficulty
|
||||
- [x] 7.2 Include duplicate stories, long filings, transcripts, contradictory reports, macro events, and opposing multi-company effects
|
||||
- [x] 7.3 Double-review a hard-case subset and calculate inter-annotator agreement
|
||||
- [x] 7.4 Freeze a holdout split that cannot be used for prompt or model tuning
|
||||
- _Requirements: 16.1_
|
||||
|
||||
- [x] 8. Implement evaluation metrics
|
||||
- [x] 8.1 Implement entity/ticker precision, recall, F1, and ambiguity accuracy
|
||||
- [x] 8.2 Implement event and relation macro/micro F1
|
||||
- [x] 8.3 Implement numeric exact/tolerance-aware matching
|
||||
- [x] 8.4 Implement evidence offset validity and support rate
|
||||
- [x] 8.5 Implement sentiment macro-F1 and probability calibration metrics
|
||||
- [x] 8.6 Implement latency, throughput, token, CPU, GPU, and memory metrics
|
||||
- [x] 8.7 Generate per-document-type and per-difficulty reports
|
||||
- _Requirements: 16.3, 16.4_
|
||||
|
||||
- [x] 9. Benchmark corrected current-model extraction
|
||||
- [x] 9.1 Run the current request unchanged
|
||||
- [x] 9.2 Run the same 9B model with temperature zero
|
||||
- [x] 9.3 Run the same 9B model with strict JSON Schema output and temperature zero
|
||||
- [x] 9.4 Quantify how much of the apparent architecture gain comes from fixing the current request alone
|
||||
- _Requirements: 16.2, 16.3, 16.5_
|
||||
|
||||
- [x] 10. Add shared inference domain models
|
||||
- [x] 10.1 Create `services/shared/inference/models.py` with capabilities, target, request, result, usage, and lineage types
|
||||
- [x] 10.2 Create normalized error categories for timeout, authentication, rate limit, server, invalid response, schema, capability, and policy failures
|
||||
- [x] 10.3 Add serialization tests proving credentials and sensitive headers are excluded
|
||||
- _Requirements: 2.1, 2.8, 2.9_
|
||||
|
||||
- [x] 11. Implement `OpenAICompatibleClient`
|
||||
- [x] 11.1 Implement `/v1/chat/completions` using `httpx.AsyncClient`
|
||||
- [x] 11.2 Implement Bearer and configurable authentication headers via runtime secret resolution
|
||||
- [x] 11.3 Implement standard `response_format.json_schema` payloads
|
||||
- [x] 11.4 Implement configurable vLLM `structured_outputs` extra-body payloads
|
||||
- [x] 11.5 Implement explicit JSON-object and prompt-only fallback policies
|
||||
- [x] 11.6 Capture request ID, usage, finish reason, structured mode, retries, and provider error category
|
||||
- [x] 11.7 Revalidate parsed JSON locally against the supplied schema
|
||||
- [x] 11.8 Add contract tests against a mocked compatible server and the cluster vLLM deployment
|
||||
- _Requirements: 2.1, 2.2, 2.3, 2.4, 2.5, 2.7, 2.9_
|
||||
|
||||
- [x] 12. Refactor Ollama support into `OllamaNativeClient`
|
||||
- [x] 12.1 Move current Ollama request logic behind the shared request/result types
|
||||
- [x] 12.2 Honor configured max output tokens and context settings consistently
|
||||
- [x] 12.3 Preserve native schema formatting when supported and explicitly report prompt-only mode otherwise
|
||||
- [x] 12.4 Retain stall/loop detection as Ollama-specific policy without leaking it into the generic protocol
|
||||
- _Requirements: 2.1, 2.6_
|
||||
|
||||
- [x] 13. Implement capability probing
|
||||
- [x] 13.1 Probe health and model listing
|
||||
- [x] 13.2 Probe strict JSON Schema with a minimal schema
|
||||
- [x] 13.3 Probe usage metadata, seed behavior, and output-token field compatibility
|
||||
- [x] 13.4 Store probe results and software/version metadata with TTL
|
||||
- [x] 13.5 Refuse activation when declared required capabilities fail
|
||||
- _Requirements: 2.10, 2.11_
|
||||
|
||||
- [x] 14. Replace provider fallback behavior
|
||||
- [x] 14.1 Replace `VLLMClient` with an alias/profile using `OpenAICompatibleClient`
|
||||
- [x] 14.2 Make unknown providers a typed configuration error
|
||||
- [x] 14.3 Add migration warnings for `vllm` provider records
|
||||
- [x] 14.4 Add property tests proving unknown providers never invoke Ollama
|
||||
- _Requirements: 2.2, 2.6_
|
||||
|
||||
- [x] 15. Migrate all LLM consumers
|
||||
- [x] 15.1 Migrate document extraction
|
||||
- [x] 15.2 Migrate global event classification
|
||||
- [x] 15.3 Migrate thesis rewriting and remove duplicate provider branching
|
||||
- [x] 15.4 Replace direct/private `_config` mutation with an explicit target refresh or client-pool lifecycle
|
||||
- [x] 15.5 Fix persistence so actual endpoint, model, and route lineage are recorded
|
||||
- _Requirements: 2.12, 13.6_
|
||||
|
||||
- [x] 16. Add registry migrations
|
||||
- [x] 16.1 Create `inference_endpoints`
|
||||
- [x] 16.2 Create `model_deployments`
|
||||
- [x] 16.3 Create `agent_stage_bindings`
|
||||
- [x] 16.4 Add revision, audit, uniqueness, and enabled-state constraints
|
||||
- [x] 16.5 Add additive lineage columns/tables for existing performance logs
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.4_
|
||||
|
||||
- [x] 17. Implement registry resolver
|
||||
- [x] 17.1 Resolve active stage bindings with TTL caching
|
||||
- [x] 17.2 Invalidate cache on revisions and failed probes
|
||||
- [x] 17.3 Resolve authentication only at invocation time
|
||||
- [x] 17.4 Add deterministic resolution and fail-closed tests
|
||||
- _Requirements: 3.5, 3.9_
|
||||
|
||||
- [x] 18. Migrate existing provider records
|
||||
- [x] 18.1 Create the current Ollama endpoint profile if in use
|
||||
- [x] 18.2 Create the current vLLM OpenAI-compatible endpoint profile
|
||||
- [x] 18.3 Create model deployments matching actual runtime state
|
||||
- [x] 18.4 Convert agent and variant provider/model fields to stage bindings while retaining compatibility reads
|
||||
- [x] 18.5 Remove conflicting runtime model defaults after migration verification
|
||||
- _Requirements: 3.8, 3.9_
|
||||
|
||||
- [x] 19. Add endpoint API and UI
|
||||
- [x] 19.1 Add CRUD endpoints that never return secret values
|
||||
- [x] 19.2 Add probe, enable, disable, and test-structured-output actions
|
||||
- [x] 19.3 Replace free-text provider inputs with protocol, endpoint, and model-deployment selectors
|
||||
- [x] 19.4 Display last probe, capabilities, model limits, and active stage bindings
|
||||
- [x] 19.5 Require confirmation for external endpoint egress enablement
|
||||
- _Requirements: 3.6, 3.7_
|
||||
|
||||
- [x] 20. Add v3 persistence tables
|
||||
- [x] 20.1 Add pipeline runs and stage runs
|
||||
- [x] 20.2 Add document chunks and evidence spans
|
||||
- [x] 20.3 Add extracted entities, facts, relations, and rejected candidates
|
||||
- [x] 20.4 Add company signal candidates and probability distributions
|
||||
- [x] 20.5 Add adjudication decisions, routing reasons, calibration references, and model lineage
|
||||
- [x] 20.6 Add idempotency and immutable-revision constraints
|
||||
- _Requirements: 13.1, 13.2, 13.3_
|
||||
|
||||
- [x] 21. Implement sentence-aware segmenter
|
||||
- [x] 21.1 Preserve source offsets and checksums
|
||||
- [x] 21.2 Add document-type-specific chunk strategies
|
||||
- [x] 21.3 Preserve filing sections and transcript speakers
|
||||
- [x] 21.4 Mark boilerplate and duplicate chunks
|
||||
- [x] 21.5 Remove the 8,000-character truncation from v3
|
||||
- [x] 21.6 Add property tests proving every chunk/evidence span maps exactly to source text
|
||||
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6_
|
||||
|
||||
- [x] 22. Implement compatibility adapter skeleton
|
||||
- [x] 22.1 Map approved v3 records to current intelligence and impact data classes
|
||||
- [x] 22.2 Persist `hybrid` lineage plus stage details
|
||||
- [x] 22.3 Add golden mapping tests for every legacy enum and field range
|
||||
- [x] 22.4 Keep adapter output disabled outside replay/shadow mode
|
||||
- _Requirements: 13.4, 13.5, 18.2_
|
||||
|
||||
- [x] 23. Implement deterministic financial parsing
|
||||
- [x] 23.1 Parse tickers, currencies, money, percentages, basis points, ranges, EPS, revenue, dates, and fiscal periods
|
||||
- [x] 23.2 Store literal and normalized representations
|
||||
- [x] 23.3 Link each candidate to exact offsets
|
||||
- [x] 23.4 Add broad property tests for numeric formatting and unit conversions
|
||||
- _Requirements: 5.1, 5.7, 5.8_
|
||||
|
||||
- [x] 24. Integrate symbol registry resolution
|
||||
- [x] 24.1 Build canonical alias indexes from existing companies and symbol registry data
|
||||
- [x] 24.2 Return ranked candidates and ambiguity margins
|
||||
- [x] 24.3 Separate explicit mentions from inferred exposures
|
||||
- [x] 24.4 Preserve unresolved literal entities without invented tickers
|
||||
- [x] 24.5 Add tests for aliases shared by multiple companies
|
||||
- _Requirements: 5.2, 5.3, 5.4, 5.5, 5.6_
|
||||
|
||||
- [x] 25. Create specialist inference service
|
||||
- [x] 25.1 Add typed batch endpoints for entities, classification, relations, and structured extraction
|
||||
- [x] 25.2 Integrate pinned GLiNER2 Large as the initial candidate
|
||||
- [x] 25.3 Return spans, scores, model version, and schema version
|
||||
- [x] 25.4 Add bounded dynamic batching and warm-up
|
||||
- [x] 25.5 Add Kubernetes CPU deployment, health probes, and metrics
|
||||
- [x] 25.6 Add contract and load tests
|
||||
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5, 6.7, 6.9_
|
||||
|
||||
- [x] 26. Integrate company-specific sentiment
|
||||
- [x] 26.1 Build company-linked evidence groups
|
||||
- [x] 26.2 Integrate pinned FinBERT baseline
|
||||
- [x] 26.3 Store full probability distributions and evidence IDs
|
||||
- [x] 26.4 Implement mixed sentiment from evidence-group disagreement
|
||||
- [x] 26.5 Benchmark and calibrate on the Gold_Corpus
|
||||
- _Requirements: 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7_
|
||||
|
||||
- [x] 27. Benchmark NuExtract 1.5 Smol
|
||||
- [x] 27.1 Add an isolated adapter and CPU/on-demand deployment
|
||||
- [x] 27.2 Test hierarchical extraction on long filings and transcripts
|
||||
- [x] 27.3 Measure incremental correctness over GLiNER2 plus deterministic parsing
|
||||
- [x] 27.4 Measure CPU latency and memory
|
||||
- [x] 27.5 Promote it only for document classes where incremental value passes a predefined gate
|
||||
- _Requirements: 6.6_
|
||||
|
||||
- [x] 28. Add evidence verification
|
||||
- [x] 28.1 Validate offsets, source text, entity association, and numeric consistency
|
||||
- [x] 28.2 Add rejected-candidate storage and reason codes
|
||||
- [x] 28.3 Benchmark a compact entailment verifier on claims exact matching cannot validate
|
||||
- [x] 28.4 Add unsupported-claim and evidence-coverage metrics
|
||||
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7_
|
||||
|
||||
- [x] 29. Implement retrieval-based novelty
|
||||
- [x] 29.1 Add exact and near-duplicate fingerprints
|
||||
- [x] 29.2 Add replaceable compact embedding backend
|
||||
- [x] 29.3 Index document and canonical company-event embeddings
|
||||
- [x] 29.4 Return nearest matches and similarity scores
|
||||
- [x] 29.5 Implement and version the novelty formula
|
||||
- [x] 29.6 Compare novelty values against human duplicate/novelty labels
|
||||
- _Requirements: 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7_
|
||||
|
||||
- [x] 30. Build confidence feature pipeline
|
||||
- [x] 30.1 Compute field-level features from extraction, resolution, evidence, sentiment, and agreement
|
||||
- [x] 30.2 Train and compare calibration methods on training folds
|
||||
- [x] 30.3 Evaluate ECE and Brier score on held-out data
|
||||
- [x] 30.4 Version and load calibration artifacts
|
||||
- [x] 30.5 Define conservative defaults for underrepresented classes
|
||||
- _Requirements: 10.1, 10.2, 10.3, 10.4, 10.6, 10.7_
|
||||
|
||||
- [x] 31. Implement deterministic routing engine
|
||||
- [x] 31.1 Define routing reason enums
|
||||
- [x] 31.2 Implement hard ambiguity/conflict rules
|
||||
- [x] 31.3 Implement calibrated fast-path thresholds by document and event type
|
||||
- [x] 31.4 Store every route decision and feature snapshot
|
||||
- [x] 31.5 Add property tests for determinism and threshold boundaries
|
||||
- _Requirements: 10.5, 11.6_
|
||||
|
||||
- [x] 32. Define adjudication schemas
|
||||
- [x] 32.1 Define candidate, conflict, question, evidence, and decision models
|
||||
- [x] 32.2 Exclude authoritative confidence, novelty, impact, and horizon from the model output
|
||||
- [x] 32.3 Require evidence IDs for every material decision
|
||||
- _Requirements: 11.2, 11.5, 11.7_
|
||||
|
||||
- [x] 33. Build focused adjudication prompts
|
||||
- [x] 33.1 Build packets from only relevant chunks and candidates
|
||||
- [x] 33.2 Use strict JSON Schema and temperature zero
|
||||
- [x] 33.3 Set a bounded output budget appropriate to decisions rather than long summaries
|
||||
- [x] 33.4 Add prompt/version metadata and exact provider lineage
|
||||
- _Requirements: 11.2, 11.3, 11.4_
|
||||
|
||||
- [x] 34. Deploy and validate the 9B adjudicator
|
||||
- [x] 34.1 Pin the approved 9B model and vLLM version
|
||||
- [x] 34.2 Verify strict structured output with the deployment's actual vLLM version
|
||||
- [x] 34.3 Measure peak VRAM against the current baseline and enforce the +5 percent gate
|
||||
- [x] 34.4 Load-test concurrency and select a safe application semaphore
|
||||
- [x] 34.5 Add availability and queue-depth alerts
|
||||
- _Requirements: 11.1, 11.10_
|
||||
|
||||
- [x] 35. Add post-adjudication verification
|
||||
- [x] 35.1 Verify every referenced evidence ID was included in the packet
|
||||
- [x] 35.2 Reject unsupported or schema-incompatible decisions
|
||||
- [x] 35.3 Preserve both pre-adjudication candidates and final decisions
|
||||
- [x] 35.4 Route repeated failures to review rather than accepting repaired defaults
|
||||
- _Requirements: 11.8, 8.7_
|
||||
|
||||
- [x] 36. Define event-time feature snapshots
|
||||
- [x] 36.1 Define feature names, types, timing rules, and missing-value policy
|
||||
- [x] 36.2 Include event, sentiment, magnitude, surprise, source, novelty, evidence, company, volatility, volume, and regime features
|
||||
- [x] 36.3 Persist immutable feature snapshots at prediction time
|
||||
- [x] 36.4 Add leakage tests preventing post-event data from entering features
|
||||
- _Requirements: 12.2, 12.10_
|
||||
|
||||
- [x] 37. Build outcome labels
|
||||
- [x] 37.1 Define approved market benchmarks and abnormal-return calculations
|
||||
- [x] 37.2 Generate signed and absolute response labels for intraday, 1d, 7d, 30d, and 90d horizons
|
||||
- [x] 37.3 Generate abnormal-volume and time-to-peak labels where data quality permits
|
||||
- [x] 37.4 Version label-generation code and market-data snapshots
|
||||
- _Requirements: 12.3_
|
||||
|
||||
- [x] 38. Implement deterministic impact baseline
|
||||
- [x] 38.1 Map event classes, sentiment, magnitude, evidence, novelty, and source credibility to conservative outputs
|
||||
- [x] 38.2 Unit-test every event type and boundary
|
||||
- [x] 38.3 Use this baseline whenever no approved trained model exists
|
||||
- _Requirements: 12.4, 12.8_
|
||||
|
||||
- [x] 39. Train calibrated tabular impact models
|
||||
- [x] 39.1 Train CPU-efficient gradient-boosted candidates for direction, magnitude, and horizon
|
||||
- [x] 39.2 Use walk-forward/out-of-time splits
|
||||
- [x] 39.3 Calibrate probabilities on a separate calibration fold
|
||||
- [x] 39.4 Report metrics by event, sector, market cap, source, and regime
|
||||
- [x] 39.5 Register artifacts, feature versions, training ranges, and model cards
|
||||
- _Requirements: 12.4, 12.5, 12.6, 12.10_
|
||||
|
||||
- [x] 40. Integrate impact outputs
|
||||
- [x] 40.1 Store full direction, magnitude, horizon, and uncertainty outputs
|
||||
- [x] 40.2 Map approved outputs to legacy `impact_score` and `impact_horizon` through the compatibility adapter
|
||||
- [x] 40.3 Remove generative impact/novelty/confidence from aggregation inputs in v3 mode
|
||||
- [x] 40.4 Add comparison dashboards against realized outcomes
|
||||
- _Requirements: 12.1, 12.7, 12.9_
|
||||
|
||||
- [x] 41. Implement v3 pipeline orchestrator
|
||||
- [x] 41.1 Create explicit stage state transitions and idempotency keys
|
||||
- [x] 41.2 Add fast-path, adjudication, persistence, and review queues
|
||||
- [x] 41.3 Implement leases, retry policies, dead-letter handling, and resumable stages
|
||||
- [x] 41.4 Keep v2 and v3 routing behind independent feature flags
|
||||
- _Requirements: 14.1, 14.2, 14.5, 14.8_
|
||||
|
||||
- [x] 42. Add bounded application parallelism
|
||||
- [x] 42.1 Replace the single sequential extraction loop for v3 with configurable async workers
|
||||
- [x] 42.2 Add specialist micro-batching
|
||||
- [x] 42.3 Add adjudicator semaphore and queue backpressure
|
||||
- [x] 42.4 Add load shedding rules that never drop safety-critical documents silently
|
||||
- _Requirements: 14.1, 14.3, 14.4, 14.5_
|
||||
|
||||
- [x] 43. Add traces and metrics
|
||||
- [x] 43.1 Trace every stage under one document trace ID
|
||||
- [x] 43.2 Add stage latency, errors, batch size, queue depth, and route metrics
|
||||
- [x] 43.3 Add field accuracy, evidence coverage, calibration, fast-path rate, and adjudication reason dashboards
|
||||
- [x] 43.4 Add GPU memory, utilization, and GPU-seconds per document
|
||||
- [x] 43.5 Add alerts for schema failures, unsupported claims, calibration drift, queue saturation, and provider probe failures
|
||||
- _Requirements: 14.7, 15.1, 15.2, 15.5_
|
||||
|
||||
- [x] 44. Add audit/review API and UI
|
||||
- [x] 44.1 Display source evidence and offsets for each fact
|
||||
- [x] 44.2 Display specialist probabilities, routing reasons, adjudicator decisions, and impact-model outputs separately
|
||||
- [x] 44.3 Allow immutable reviewer correction events
|
||||
- [x] 44.4 Add filters for low confidence, unsupported claims, and adjudicated documents
|
||||
- _Requirements: 15.3, 15.4, 15.6, 15.7_
|
||||
|
||||
- [x] 45. Run offline replay
|
||||
- [x] 45.1 Compare every required system configuration on the Gold_Corpus
|
||||
- [x] 45.2 Publish field-level, calibration, resource, and difficulty-bucket reports
|
||||
- [x] 45.3 Confirm corrected current-9B baseline versus full v3 incremental gain
|
||||
- [x] 45.4 Reject or retune any stage failing safety-critical gates
|
||||
- _Requirements: 16.2, 16.3, 16.4, 16.5_
|
||||
|
||||
- [x] 46. Enable production shadow mode
|
||||
- [x] 46.1 Run v3 for live documents without affecting aggregation or trading
|
||||
- [x] 46.2 Compare v2/v3 disagreements and sample reviews by risk
|
||||
- [x] 46.3 Measure fast-path coverage, GPU reduction, and operational stability
|
||||
- [x] 46.4 Require the configured minimum shadow duration and document count
|
||||
- _Requirements: 16.6, 16.7, 16.8_
|
||||
|
||||
- [x] 47. Canary compatibility outputs
|
||||
- [x] 47.1 Enable v3 adapter outputs for non-trading consumers first
|
||||
- [x] 47.2 Add percentage- and document-type-based routing
|
||||
- [x] 47.3 Configure automatic rollback on correctness, latency, queue, or availability thresholds
|
||||
- [x] 47.4 Verify rollback leaves v3 audit records intact
|
||||
- _Requirements: 16.9, 18.4, 18.5_
|
||||
|
||||
- [x] 48. Canary signal influence
|
||||
- [x] 48.1 Enable v3 signals in paper trading at a small percentage
|
||||
- [x] 48.2 Report extraction correctness separately from trading outcomes
|
||||
- [x] 48.3 Review material recommendation divergences
|
||||
- [x] 48.4 Promote only after explicit owner approval and all gates pass
|
||||
- _Requirements: 16.9, 16.10_
|
||||
|
||||
- [x] 49. Build active-learning export
|
||||
- [x] 49.1 Select low-confidence, conflicting, adjudicated, and corrected cases
|
||||
- [x] 49.2 Remove or policy-filter sensitive content
|
||||
- [x] 49.3 Export source spans, labels, relations, decisions, and provenance in a versioned format
|
||||
- _Requirements: 17.1, 17.2_
|
||||
|
||||
- [x] 50. Fine-tune specialist extractor
|
||||
- [x] 50.1 Train GLiNER2 candidate artifacts on the Stonks Oracle schema
|
||||
- [x] 50.2 Evaluate against frozen holdout and production artifact
|
||||
- [x] 50.3 Calibrate new scores and update routing thresholds
|
||||
- [x] 50.4 Promote only when correctness gates pass, not merely when adjudication rate falls
|
||||
- _Requirements: 17.3, 17.4, 17.5, 17.6_
|
||||
|
||||
- [x] 51. Deprecate legacy paths
|
||||
- [x] 51.1 Remove duplicated `VLLMClient`/provider branching after all consumers use the gateway
|
||||
- [x] 51.2 Remove v2 8,000-character truncation and monolithic extraction prompt after v2 retirement
|
||||
- [x] 51.3 Remove obsolete environment/model defaults and provider free-text fields
|
||||
- [x] 51.4 Remove compatibility adapter only after every downstream consumer reads v3 natively
|
||||
- [x] 51.5 Archive final migration and benchmark reports
|
||||
- _Requirements: 18.6_
|
||||
|
||||
- [x] 52. Checkpoint — Ensure all tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
## Task Dependency Graph
|
||||
|
||||
```json
|
||||
{
|
||||
"waves": [
|
||||
{ "id": 0, "tasks": ["1.1", "1.2", "1.3", "1.4", "1.5", "1.6", "2.1", "2.2", "2.3", "2.4", "3.1", "3.2", "3.3", "4.1", "4.2", "4.3", "4.4", "5.1", "5.2", "5.3", "5.4"] },
|
||||
{ "id": 1, "tasks": ["6.1", "6.2", "6.3", "6.4", "7.1", "7.2", "7.3", "7.4", "8.1", "8.2", "8.3", "8.4", "8.5", "8.6", "8.7", "9.1", "9.2", "9.3", "9.4"] },
|
||||
{ "id": 2, "tasks": ["10.1", "10.2", "10.3", "11.1", "11.2", "11.3", "11.4", "11.5", "11.6", "11.7", "11.8", "12.1", "12.2", "12.3", "12.4"] },
|
||||
{ "id": 3, "tasks": ["13.1", "13.2", "13.3", "13.4", "13.5", "14.1", "14.2", "14.3", "14.4", "15.1", "15.2", "15.3", "15.4", "15.5", "16.1", "16.2", "16.3", "16.4", "16.5"] },
|
||||
{ "id": 4, "tasks": ["17.1", "17.2", "17.3", "17.4", "18.1", "18.2", "18.3", "18.4", "18.5", "19.1", "19.2", "19.3", "19.4", "19.5", "20.1", "20.2", "20.3", "20.4", "20.5", "20.6", "21.1", "21.2", "21.3", "21.4", "21.5", "21.6", "22.1", "22.2", "22.3", "22.4"] },
|
||||
{ "id": 5, "tasks": ["23.1", "23.2", "23.3", "23.4", "24.1", "24.2", "24.3", "24.4", "24.5", "25.1", "25.2", "25.3", "25.4", "25.5", "25.6", "26.1", "26.2", "26.3", "26.4", "26.5", "27.1", "27.2", "27.3", "27.4", "27.5", "28.1", "28.2", "28.3", "28.4"] },
|
||||
{ "id": 6, "tasks": ["29.1", "29.2", "29.3", "29.4", "29.5", "29.6", "30.1", "30.2", "30.3", "30.4", "30.5", "31.1", "31.2", "31.3", "31.4", "31.5"] },
|
||||
{ "id": 7, "tasks": ["32.1", "32.2", "32.3", "33.1", "33.2", "33.3", "33.4", "34.1", "34.2", "34.3", "34.4", "34.5", "35.1", "35.2", "35.3", "35.4"] },
|
||||
{ "id": 8, "tasks": ["36.1", "36.2", "36.3", "36.4", "37.1", "37.2", "37.3", "37.4", "38.1", "38.2", "38.3", "39.1", "39.2", "39.3", "39.4", "39.5", "40.1", "40.2", "40.3", "40.4"] },
|
||||
{ "id": 9, "tasks": ["41.1", "41.2", "41.3", "41.4", "42.1", "42.2", "42.3", "42.4", "43.1", "43.2", "43.3", "43.4", "43.5", "44.1", "44.2", "44.3", "44.4"] },
|
||||
{ "id": 10, "tasks": ["45.1", "45.2", "45.3", "45.4", "46.1", "46.2", "46.3", "46.4", "47.1", "47.2", "47.3", "47.4", "48.1", "48.2", "48.3", "48.4"] },
|
||||
{ "id": 11, "tasks": ["49.1", "49.2", "49.3", "50.1", "50.2", "50.3", "50.4", "51.1", "51.2", "51.3", "51.4", "51.5"] }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- This plan is intentionally staged so the current system remains available until the replacement is measured and promoted
|
||||
- Task 1 (credential rotation) is a **BLOCKER** — must complete before any feature deployment
|
||||
- Tasks within the same wave may run in parallel; tasks in later waves depend on earlier waves completing
|
||||
- Each phase ends with an explicit evidence artifact: test output, benchmark report, migration result, or deployment probe
|
||||
- The current v2 extractor remains available behind a feature flag until v3 completes shadow and canary promotion
|
||||
- Peak GPU memory must not exceed the measured current 9B deployment baseline by more than 5 percent
|
||||
- The definition of done requires: credentials rotated, all consumers on shared gateway, evidence-linked outputs, calibrated scores replacing generative self-scores, 9B preserved for adjudication, and shadow/canary gates passed
|
||||
- Rollback to the current production path must be exercised successfully before full promotion
|
||||
- Property tests validate deterministic behaviors (unknown providers fail closed, chunk offsets map to source, routing thresholds are deterministic)
|
||||
- Deprecated legacy paths (task 51) require separate approval and must not proceed until all downstream consumers read v3 natively
|
||||
@@ -0,0 +1 @@
|
||||
{"specId": "ff0d03d7-3469-4551-bf05-15295b735c83", "workflowType": "requirements-first", "specType": "feature"}
|
||||
@@ -0,0 +1,851 @@
|
||||
# Design Document: Math Core v3 Engine
|
||||
|
||||
## Overview
|
||||
|
||||
The v3 Calibrated Evidence Engine replaces the current dual-mode pipeline (heuristic + probabilistic) with a principled Bayesian evidence accumulation system. The upgrade transforms the signal processing core from weighted-sentiment averaging to:
|
||||
|
||||
```
|
||||
EvidenceUnit → calibrated reliability (q_i) → log-likelihood ratio (LLR_i)
|
||||
→ correlation-adjusted cluster LLR → posterior P_up → return distribution → EV/risk decision
|
||||
```
|
||||
|
||||
**Key design goals:**
|
||||
- Replace arbitrary weight products with calibrated probabilistic evidence
|
||||
- Prevent correlated articles from inflating evidence counts
|
||||
- Make confidence multiplicative so one bad dimension suppresses the trade
|
||||
- Size positions using fractional Kelly criterion under hard risk caps
|
||||
- Preserve the existing three-layer architecture and service boundaries
|
||||
- Gate behind `v3_engine_enabled` feature flag with heuristic fallback
|
||||
|
||||
**What changes vs. what stays:**
|
||||
- The `WeightedSignal` abstraction remains as an intermediate before LLR conversion
|
||||
- All output goes into existing JSONB metadata columns (no new migrations)
|
||||
- Service file boundaries are preserved; internals are upgraded
|
||||
- The heuristic pipeline stays as fallback, controlled by a single flag read per aggregation cycle
|
||||
|
||||
## Architecture
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph Input Layer
|
||||
CS[Company Signals]
|
||||
MS[Macro Signals]
|
||||
XS[Competitive Signals]
|
||||
end
|
||||
|
||||
subgraph Normalization
|
||||
EU[EvidenceUnit Normalization]
|
||||
end
|
||||
|
||||
subgraph Scoring Pipeline
|
||||
QI[Calibrated Reliability q_i]
|
||||
LLR[LLR Conversion]
|
||||
end
|
||||
|
||||
subgraph Clustering
|
||||
CL[Correlation-Aware Clustering]
|
||||
NEFF[n_eff Computation]
|
||||
CLLR[Cluster LLR]
|
||||
end
|
||||
|
||||
subgraph Posterior Assembly
|
||||
REG[Regime Detection v3]
|
||||
POST[Log-Odds Posterior P_up]
|
||||
CON[LLR Entropy Contradiction]
|
||||
CONF[Multiplicative Confidence]
|
||||
end
|
||||
|
||||
subgraph Decision Layer
|
||||
PROJ[Posterior State Projection]
|
||||
RET[Return Distribution / EV Gate]
|
||||
ELIG[Regime-Aware Eligibility]
|
||||
KELLY[Fractional Kelly Sizing]
|
||||
STOP[Regime-Aware Stops]
|
||||
HEAT[Stop-Defined Portfolio Heat]
|
||||
end
|
||||
|
||||
subgraph Quality & Control
|
||||
DQ[Data Quality v3]
|
||||
FF[Feature Flag Router]
|
||||
TIER[Risk Tier Auto-Adjustment]
|
||||
end
|
||||
|
||||
CS --> EU
|
||||
MS --> EU
|
||||
XS --> EU
|
||||
EU --> QI
|
||||
QI --> LLR
|
||||
LLR --> CL
|
||||
CL --> NEFF
|
||||
NEFF --> CLLR
|
||||
REG --> POST
|
||||
CLLR --> POST
|
||||
POST --> CON
|
||||
POST --> CONF
|
||||
CONF --> PROJ
|
||||
PROJ --> RET
|
||||
RET --> ELIG
|
||||
ELIG --> KELLY
|
||||
KELLY --> STOP
|
||||
KELLY --> HEAT
|
||||
DQ --> CONF
|
||||
FF --> EU
|
||||
TIER --> KELLY
|
||||
```
|
||||
|
||||
### Service File Mapping
|
||||
|
||||
| Service File | v3 Responsibility |
|
||||
|---|---|
|
||||
| `services/aggregation/scoring.py` | EvidenceUnit normalization, q_i pipeline, LLR conversion |
|
||||
| `services/aggregation/bayesian.py` | Posterior assembly via log-odds, P_up, strength |
|
||||
| `services/aggregation/contradiction.py` | LLR entropy contradiction score |
|
||||
| `services/aggregation/regime.py` | Regime detection v3 (ATR-normalized trend_z) |
|
||||
| `services/aggregation/interpolation.py` | Noisy-OR macro exposure, LLR emission |
|
||||
| `services/aggregation/signal_propagation.py` | Correlation-shrunk competitive propagation |
|
||||
| `services/aggregation/projection.py` | Posterior state A_t, regime-aware decay |
|
||||
| `services/aggregation/worker.py` | Orchestration, clustering, n_eff, confidence assembly |
|
||||
| `services/recommendation/eligibility.py` | EV gate, regime-aware eligibility, mode escalation |
|
||||
| `services/trading/position_sizer.py` | Fractional Kelly sizing under caps |
|
||||
| `services/trading/stop_loss_manager.py` | Regime-aware stop/TP, trailing activation |
|
||||
| `services/risk/engine.py` | Stop-defined heat, tier auto-adjustment |
|
||||
|
||||
### Feature Flag Flow
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Worker as aggregation/worker.py
|
||||
participant DB as risk_configs table
|
||||
participant V3 as v3 Pipeline
|
||||
participant Heuristic as Heuristic Pipeline
|
||||
|
||||
Worker->>DB: SELECT v3_engine_enabled
|
||||
alt v3_engine_enabled = True
|
||||
Worker->>V3: Run v3 pipeline
|
||||
V3-->>Worker: Posterior + confidence + EV
|
||||
alt Unhandled error
|
||||
V3-->>Worker: Exception
|
||||
Worker->>Heuristic: Fallback to heuristic
|
||||
Worker->>Worker: Log error, record fallback in metadata
|
||||
end
|
||||
else v3_engine_enabled = False or DB error
|
||||
Worker->>Heuristic: Run heuristic pipeline
|
||||
end
|
||||
```
|
||||
|
||||
## Components and Interfaces
|
||||
|
||||
### 1. EvidenceUnit Dataclass (`scoring.py`)
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class EvidenceUnit:
|
||||
"""Canonical normalized signal representation for v3 pipeline."""
|
||||
symbol: str
|
||||
layer: str # "company" | "macro" | "competitive"
|
||||
event_type: str
|
||||
source_id: str
|
||||
source_group: str
|
||||
timestamp: datetime
|
||||
horizon: str # "intraday" | "1d" | "7d" | "30d" | "90d"
|
||||
direction: int # -1, 0, +1
|
||||
sentiment_strength: float # [0, 1]
|
||||
impact: float # [0, 1]
|
||||
extraction_conf: float # [0, 1]
|
||||
source_cred: float # [0, 1]
|
||||
novelty: float # [0, 1]
|
||||
event_base_rate: float # (0, 1]
|
||||
cluster_id: str
|
||||
```
|
||||
|
||||
**Normalization functions** — one per layer:
|
||||
- `normalize_company_signal(impact_row, ...) -> EvidenceUnit`
|
||||
- `normalize_macro_signal(macro_impact_record, global_event, ...) -> EvidenceUnit`
|
||||
- `normalize_competitive_signal(competitive_signal_record, ...) -> EvidenceUnit`
|
||||
|
||||
Each validates required fields (symbol, timestamp, source_id), substitutes 0.5 for missing optional numeric fields, and assigns direction from sentiment/impact_direction strings.
|
||||
|
||||
### 2. Calibrated Reliability Pipeline (`scoring.py`)
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class ReliabilityComponents:
|
||||
q_ext: float
|
||||
q_source: float
|
||||
q_recency: float
|
||||
q_uniqueness: float
|
||||
q_i: float # final combined reliability
|
||||
|
||||
def compute_v3_reliability(
|
||||
unit: EvidenceUnit,
|
||||
source_stats: SourceStats,
|
||||
cluster_position: int, # duplicate_count_before
|
||||
reference_time: datetime,
|
||||
) -> ReliabilityComponents: ...
|
||||
```
|
||||
|
||||
Sub-computations:
|
||||
- `q_ext = sigmoid(8.0 * (extraction_conf - 0.55))`
|
||||
- `q_source = clamp((E[theta_s] - 0.50) / 0.35, 0, 1)` with Beta(alpha_0+hits, beta_0+misses)
|
||||
- `q_recency = 2^(-age_hours / tau_adaptive)` with adaptive half-life
|
||||
- `q_uniqueness = clamp(0.5 + 0.5 * novelty, 0.5, 1.0) * (1 / sqrt(1 + dup_count))`
|
||||
- `q_i = clamp(q_ext * q_source * source_cred * q_recency * q_uniqueness, 0, 1)`
|
||||
|
||||
### 3. LLR Conversion (`scoring.py`)
|
||||
|
||||
```python
|
||||
def compute_llr(unit: EvidenceUnit, q_i: float) -> float:
|
||||
"""Convert calibrated reliability to log-likelihood ratio."""
|
||||
p_correct = clamp(0.50 + 0.35 * q_i * unit.impact * unit.sentiment_strength, 0.501, 0.85)
|
||||
if unit.direction == 0:
|
||||
return 0.0
|
||||
return unit.direction * math.log(p_correct / (1 - p_correct))
|
||||
```
|
||||
|
||||
### 4. Correlation-Aware Clustering (`worker.py`)
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class EvidenceCluster:
|
||||
cluster_id: str
|
||||
units: list[EvidenceUnit]
|
||||
llrs: list[float]
|
||||
n_eff: float
|
||||
cluster_llr: float
|
||||
|
||||
def cluster_evidence(units: list[EvidenceUnit], llrs: list[float]) -> list[EvidenceCluster]:
|
||||
"""Group by (symbol, horizon, event_type, source_group, time_bucket)."""
|
||||
...
|
||||
|
||||
def compute_n_eff(llrs: list[float], correlations: list[list[float]]) -> float:
|
||||
"""n_eff = (sum w_i)^2 / (sum w_i^2 + 2*sum_{i<j} rho_ij*w_i*w_j)"""
|
||||
...
|
||||
|
||||
def compute_cluster_llr(llrs: list[float], n_eff: float) -> float:
|
||||
"""LLR_c = clamp(weighted_mean(LLR_i, |LLR_i|) * sqrt(n_eff), -2.5, 2.5)"""
|
||||
...
|
||||
```
|
||||
|
||||
Default pairwise correlations:
|
||||
| Relationship | rho |
|
||||
|---|---:|
|
||||
| Same wire/story/source group | 0.80 |
|
||||
| Same event, different publisher | 0.50 |
|
||||
| Same theme, different event | 0.25 |
|
||||
| Independent events | 0.00 |
|
||||
|
||||
### 5. Posterior Assembly (`bayesian.py`)
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class V3Posterior:
|
||||
p_up: float # sigmoid(log_odds)
|
||||
p_down: float # 1 - p_up
|
||||
log_odds: float # logit(P_prior) + sum(gamma * LLR_c)
|
||||
strength: float # abs(2 * p_up - 1)
|
||||
direction: str # bullish | bearish | neutral
|
||||
n_eff_total: float
|
||||
regime: str
|
||||
|
||||
def compute_v3_posterior(
|
||||
clusters: list[EvidenceCluster],
|
||||
regime: RegimeClassification,
|
||||
p_prior: float = 0.50,
|
||||
) -> V3Posterior: ...
|
||||
```
|
||||
|
||||
Direction thresholds by regime:
|
||||
| Regime | Bullish if P_up >= | Bearish if P_up <= |
|
||||
|---|---:|---:|
|
||||
| panic | 0.68 | 0.32 |
|
||||
| trend_following | 0.60 | 0.40 |
|
||||
| mean_reversion | 0.63 | 0.37 |
|
||||
| uncertainty | 0.65 | 0.35 |
|
||||
|
||||
### 6. Regime Detection v3 (`regime.py`)
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class V3RegimeClassification:
|
||||
regime: MarketRegime
|
||||
trend_z: float # (EMA_20 - EMA_100) / ATR_20
|
||||
vol_ratio: float # sigma_20 / sigma_100
|
||||
evidence_multiplier: float # gamma_regime
|
||||
confidence_multiplier: float
|
||||
phi_decay: float # for projection
|
||||
atr_multiplier: float # for stops
|
||||
|
||||
def classify_regime_v3(
|
||||
closing_prices: list[float],
|
||||
daily_returns: list[float],
|
||||
atr_20: float,
|
||||
) -> V3RegimeClassification: ...
|
||||
```
|
||||
|
||||
Classification rules (in priority order):
|
||||
1. **Panic**: vol_ratio > 1.5 OR abs(trend_z) > 2.5
|
||||
2. **Trend following**: abs(trend_z) >= 0.75 AND vol_ratio < 1.3
|
||||
3. **Mean reversion**: abs(trend_z) < 0.50 AND vol_ratio < 1.0
|
||||
4. **Uncertainty**: all other cases
|
||||
|
||||
### 7. LLR Entropy Contradiction (`contradiction.py`)
|
||||
|
||||
```python
|
||||
def compute_v3_contradiction(clusters: list[EvidenceCluster]) -> float:
|
||||
"""
|
||||
E_pos = sum(max(LLR_c, 0))
|
||||
E_neg = sum(max(-LLR_c, 0))
|
||||
H = -f_pos*log2(f_pos) - f_neg*log2(f_neg)
|
||||
volume_factor = 1 - exp(-E_total / 3.0)
|
||||
return H * volume_factor
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
### 8. Multiplicative Confidence (`worker.py`)
|
||||
|
||||
```python
|
||||
def compute_v3_confidence(
|
||||
n_eff_total: float,
|
||||
q_values: list[float],
|
||||
llrs: list[float],
|
||||
strength: float,
|
||||
regime_confidence_mult: float,
|
||||
contradiction: float,
|
||||
data_quality: float,
|
||||
) -> float:
|
||||
"""
|
||||
C_evidence = 1 - exp(-n_eff_total / 5.0)
|
||||
C_quality = weighted_mean(q_i, |LLR_i|)
|
||||
confidence = clamp(
|
||||
C_evidence * sqrt(C_quality) * sqrt(max(strength, 0.05))
|
||||
* regime_confidence_mult * (1 - contradiction) * data_quality,
|
||||
0, 1
|
||||
)
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
### 9. Noisy-OR Macro Exposure (`interpolation.py`)
|
||||
|
||||
```python
|
||||
def compute_normalized_macro_exposure(overlaps: dict[str, float]) -> float:
|
||||
"""
|
||||
E_raw = 1 - prod(1 - w_k * O_k)
|
||||
E_max = 1 - prod(1 - w_k)
|
||||
return E_raw / E_max
|
||||
"""
|
||||
...
|
||||
|
||||
def compute_macro_llr(
|
||||
macro_impact: float,
|
||||
event_confidence: float,
|
||||
q_recency: float,
|
||||
macro_direction: int,
|
||||
) -> float:
|
||||
"""
|
||||
p_macro = clamp(0.50 + 0.30 * macro_impact * event_confidence * q_recency, 0.501, 0.80)
|
||||
return macro_direction * log(p_macro / (1 - p_macro))
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
### 10. Correlation-Shrunk Competitive Propagation (`signal_propagation.py`)
|
||||
|
||||
```python
|
||||
def compute_shrunk_correlation(
|
||||
rho_rolling: float,
|
||||
n_observations: int,
|
||||
same_sector: bool,
|
||||
) -> float:
|
||||
"""
|
||||
rho_prior = 0.30 if same_sector else 0.10
|
||||
rho_shrunk = (n/(n+30)) * rho_rolling + (30/(n+30)) * rho_prior
|
||||
return max(rho_shrunk, 0)
|
||||
"""
|
||||
...
|
||||
|
||||
def compute_competitive_llr(
|
||||
llr_source: float,
|
||||
rho_effective: float,
|
||||
d_network: int,
|
||||
pattern_confidence: float,
|
||||
) -> float:
|
||||
"""
|
||||
attenuation = rho_effective * exp(-0.85 * d_network)
|
||||
return clamp(llr_source * attenuation * pattern_confidence, -1.25, 1.25)
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
### 11. Posterior State Projection (`projection.py`)
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class V3ProjectionState:
|
||||
a_t: float # accumulated evidence state
|
||||
p_up_projected: float # sigmoid(logit(P_prior) + phi^h * A_t)
|
||||
projected_strength: float
|
||||
diverges: bool
|
||||
phi_regime: float
|
||||
|
||||
def compute_v3_projection(
|
||||
a_prev: float,
|
||||
cluster_llrs: list[float],
|
||||
regime: V3RegimeClassification,
|
||||
p_prior: float,
|
||||
projection_horizon: int,
|
||||
known_catalyst_llr: float = 0.0,
|
||||
) -> V3ProjectionState: ...
|
||||
```
|
||||
|
||||
Regime decay factors (phi):
|
||||
| Regime | phi |
|
||||
|---|---:|
|
||||
| panic | 0.35 |
|
||||
| trend_following | 0.80 |
|
||||
| mean_reversion | 0.55 |
|
||||
| uncertainty | 0.50 |
|
||||
|
||||
### 12. Return Distribution and EV Gate (`eligibility.py`)
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class ReturnDistribution:
|
||||
sigma_h: float # realized_vol_20d * sqrt(horizon_days / 252)
|
||||
mu_h: float # tanh(A_projected / 3.0) * confidence * sigma_h
|
||||
ev_long: float # mu_h - costs - 0.10 * CVaR_5
|
||||
min_edge: float # regime-specific minimum edge
|
||||
eligible: bool
|
||||
|
||||
def compute_return_distribution(
|
||||
a_projected: float,
|
||||
confidence: float,
|
||||
realized_vol_20d: float,
|
||||
horizon_days: int,
|
||||
costs: float,
|
||||
regime: str,
|
||||
) -> ReturnDistribution: ...
|
||||
```
|
||||
|
||||
### 13. Fractional Kelly Position Sizing (`position_sizer.py`)
|
||||
|
||||
```python
|
||||
def compute_kelly_sizing(
|
||||
p_win: float, # P_up from posterior
|
||||
b: float, # reward ratio: clamp(1.2 + 2*conf + str - contra, 1.2, 3.0)
|
||||
confidence: float,
|
||||
data_quality: float,
|
||||
contradiction: float,
|
||||
max_position_pct: float,
|
||||
available_caps: dict[str, float], # sector, correlation, heat capacities
|
||||
) -> float:
|
||||
"""
|
||||
f_kelly = (p_win * b - (1 - p_win)) / b
|
||||
portfolio_pct = clamp(max(0, f_kelly) * 0.25 * confidence * data_quality * (1 - contradiction), 0, max_position_pct)
|
||||
Apply min of all capacity constraints.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
### 14. Stop-Defined Portfolio Heat (`risk/engine.py`)
|
||||
|
||||
```python
|
||||
def compute_portfolio_heat(
|
||||
positions: list[OpenPosition],
|
||||
stop_distances: dict[str, float],
|
||||
) -> float:
|
||||
"""risk_dollars = position_value * stop_distance_pct; heat = sum(risk_dollars)"""
|
||||
...
|
||||
|
||||
def check_heat_capacity(
|
||||
current_heat: float,
|
||||
new_risk_dollars: float,
|
||||
max_heat_pct: float,
|
||||
portfolio_value: float,
|
||||
) -> bool: ...
|
||||
```
|
||||
|
||||
### 15. Data Quality v3 (`worker.py`)
|
||||
|
||||
```python
|
||||
def compute_v3_data_quality(
|
||||
units: list[EvidenceUnit],
|
||||
extraction_failure_rate: float,
|
||||
age_newest_hours: float,
|
||||
n_source_types: int,
|
||||
) -> float:
|
||||
"""
|
||||
Q_parse = 1 - extraction_failure_rate
|
||||
Q_conf = weighted_mean(extraction_conf, impact)
|
||||
Q_fresh = exp(-age_newest_hours / 168)
|
||||
Q_coverage = 1 - exp(-N_valid / 5)
|
||||
Q_diversity = min(1, log2(1 + N_source_types) / log2(4))
|
||||
return clamp(Q_parse * sqrt(Q_conf) * Q_fresh * Q_coverage * Q_diversity, 0, 1)
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
### 16. Risk Tier Auto-Adjustment (`risk/engine.py`)
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class TierMetrics:
|
||||
profit_factor_30d: float
|
||||
max_drawdown_30d: float
|
||||
calibration_error: float
|
||||
realized_sharpe_30d: float
|
||||
n_trades_30d: int
|
||||
reserve_pool_pct: float
|
||||
|
||||
def evaluate_tier_adjustment(metrics: TierMetrics) -> str:
|
||||
"""Returns 'upgrade' | 'downgrade' | 'hold'"""
|
||||
...
|
||||
```
|
||||
|
||||
## Data Models
|
||||
|
||||
### EvidenceUnit (frozen dataclass)
|
||||
|
||||
| Field | Type | Range | Source |
|
||||
|---|---|---|---|
|
||||
| symbol | str | — | Required from signal |
|
||||
| layer | str | company/macro/competitive | Set during normalization |
|
||||
| event_type | str | — | catalyst_type or impact_type |
|
||||
| source_id | str | — | document_id or event_id |
|
||||
| source_group | str | — | publisher / "macro" / "competitive" |
|
||||
| timestamp | datetime | — | published_at |
|
||||
| horizon | str | intraday/1d/7d/30d/90d | window or estimated_duration mapping |
|
||||
| direction | int | -1, 0, +1 | sentiment/direction mapping |
|
||||
| sentiment_strength | float | [0, 1] | impact_score or sentiment confidence |
|
||||
| impact | float | [0, 1] | impact_score |
|
||||
| extraction_conf | float | [0, 1] | confidence field |
|
||||
| source_cred | float | [0, 1] | source_credibility |
|
||||
| novelty | float | [0, 1] | novelty_score |
|
||||
| event_base_rate | float | (0, 1] | lookup by event_type |
|
||||
| cluster_id | str | — | computed hash of clustering key |
|
||||
|
||||
### V3 Posterior Output (stored in JSONB metadata)
|
||||
|
||||
```json
|
||||
{
|
||||
"v3_posterior": {
|
||||
"p_up": 0.64,
|
||||
"p_down": 0.36,
|
||||
"log_odds": 0.58,
|
||||
"strength": 0.28,
|
||||
"confidence": 0.61,
|
||||
"contradiction": 0.18,
|
||||
"n_eff": 5.7,
|
||||
"data_quality": 0.82,
|
||||
"regime": "trend_following"
|
||||
},
|
||||
"v3_return_model": {
|
||||
"mu_h": 0.012,
|
||||
"sigma_h": 0.041,
|
||||
"ev_long": 0.007,
|
||||
"min_edge": 0.0035
|
||||
},
|
||||
"v3_explainability": {
|
||||
"top_positive_clusters": [...],
|
||||
"top_negative_clusters": [...],
|
||||
"suppression_reasons": [],
|
||||
"risk_adjustments": []
|
||||
},
|
||||
"pipeline_mode": "v3"
|
||||
}
|
||||
```
|
||||
|
||||
### Source Statistics (for q_source computation)
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class SourceStats:
|
||||
source_id: str
|
||||
hits: int = 0 # correct directional predictions
|
||||
misses: int = 0 # incorrect directional predictions
|
||||
alpha_0: int = 3 # prior
|
||||
beta_0: int = 3 # prior
|
||||
```
|
||||
|
||||
### Regime Parameters Table
|
||||
|
||||
| Regime | gamma (evidence) | confidence_mult | phi (decay) | ATR_mult (stops) | min_edge |
|
||||
|---|---:|---:|---:|---:|---:|
|
||||
| panic | 0.70 | 0.70 | 0.35 | 2.5 | 0.0100 |
|
||||
| trend_following | 1.10 | 1.00 | 0.80 | 1.8 | 0.0035 |
|
||||
| mean_reversion | 0.90 | 0.95 | 0.55 | 1.4 | 0.0050 |
|
||||
| uncertainty | 0.80 | 0.85 | 0.50 | 2.0 | 0.0075 |
|
||||
|
||||
### Eligibility Thresholds (Regime-Specific)
|
||||
|
||||
| Regime | confidence_min | contradiction_max | strength_min |
|
||||
|---|---:|---:|---:|
|
||||
| panic | 0.70 | 0.25 | 0.36 |
|
||||
| trend_following | 0.55 | 0.40 | 0.20 |
|
||||
| mean_reversion | 0.60 | 0.35 | 0.26 |
|
||||
| uncertainty | 0.65 | 0.30 | 0.30 |
|
||||
|
||||
|
||||
## Correctness Properties
|
||||
|
||||
*A property is a characteristic or behavior that should hold true across all valid executions of a system — essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
|
||||
|
||||
### Property 1: Reliability q_i is bounded in [0, 1]
|
||||
|
||||
*For any* valid EvidenceUnit with extraction_conf in [0,1], source_cred in [0,1], novelty in [0,1], any non-negative age_hours, and any non-negative duplicate_count_before, the computed q_i SHALL be in the range [0.0, 1.0].
|
||||
|
||||
**Validates: Requirements 2.8, 21.1**
|
||||
|
||||
### Property 2: p_correct is bounded in [0.501, 0.85]
|
||||
|
||||
*For any* valid q_i in [0, 1], impact in [0, 1], and sentiment_strength in [0, 1], the computed p_correct SHALL be in the range [0.501, 0.85].
|
||||
|
||||
**Validates: Requirements 3.1, 21.2**
|
||||
|
||||
### Property 3: LLR sign matches direction and magnitude is bounded
|
||||
|
||||
*For any* valid signal with direction in {-1, +1}, the computed LLR SHALL have the same sign as direction, with absolute magnitude in [ln(0.501/0.499), ln(0.85/0.15)] ≈ [0.004, 1.735].
|
||||
|
||||
**Validates: Requirements 3.2, 3.4, 3.5, 3.6, 21.3**
|
||||
|
||||
### Property 4: Neutral signals produce zero LLR
|
||||
|
||||
*For any* valid EvidenceUnit with direction = 0, regardless of all other field values, the computed LLR SHALL be exactly 0.0.
|
||||
|
||||
**Validates: Requirements 1.5, 3.3**
|
||||
|
||||
### Property 5: Effective evidence count n_eff is bounded by cluster size
|
||||
|
||||
*For any* cluster of N signals with non-negative pairwise correlations rho_ij in [0, 1], the computed n_eff SHALL satisfy 0 < n_eff <= N.
|
||||
|
||||
**Validates: Requirements 4.2, 21.4**
|
||||
|
||||
### Property 6: Cluster LLR is clamped to [-2.5, 2.5]
|
||||
|
||||
*For any* cluster configuration with any number of signals and any LLR values, the computed cluster LLR_c SHALL be in the range [-2.5, 2.5].
|
||||
|
||||
**Validates: Requirements 4.4, 4.5**
|
||||
|
||||
### Property 7: Posterior P_up is in open interval (0, 1)
|
||||
|
||||
*For any* set of cluster LLRs (each in [-2.5, 2.5]), any regime evidence multiplier gamma in {0.70, 0.80, 0.90, 1.10}, and any prior P_prior in [0.40, 0.60], the computed P_up SHALL be in (1e-10, 1 - 1e-10).
|
||||
|
||||
**Validates: Requirements 5.3, 21.5**
|
||||
|
||||
### Property 8: Contradiction is zero when evidence is unidirectional
|
||||
|
||||
*For any* set of cluster LLRs where all clusters have the same sign (all positive or all negative), the computed contradiction score SHALL be 0.0.
|
||||
|
||||
**Validates: Requirements 7.7, 21.7**
|
||||
|
||||
### Property 9: Contradiction score is bounded in [0, 1]
|
||||
|
||||
*For any* set of cluster LLRs (including mixed positive and negative), the computed contradiction score SHALL be in the range [0.0, 1.0].
|
||||
|
||||
**Validates: Requirements 7.6**
|
||||
|
||||
### Property 10: Multiplicative confidence is bounded in [0, 1] and suppressed by weak dimensions
|
||||
|
||||
*For any* valid inputs (n_eff_total >= 0, q_values in [0,1], strength in [0,1], regime_confidence_mult in (0,1], contradiction in [0,1], data_quality in [0,1]), the computed confidence SHALL be in [0, 1]. Furthermore, if any single dimension (data_quality, 1-contradiction, or C_quality) is below 0.01, the resulting confidence SHALL be below 0.10.
|
||||
|
||||
**Validates: Requirements 8.3, 8.5, 21.6**
|
||||
|
||||
### Property 11: Fractional Kelly sizing is bounded and respects negative edge
|
||||
|
||||
*For any* valid inputs (P_up in (0,1), b in [1.2, 3.0], confidence in [0,1], data_quality in [0,1], contradiction in [0,1], max_position_pct > 0), the computed portfolio_pct SHALL be in [0, max_position_pct]. When f_kelly = (P_up * b - (1 - P_up)) / b <= 0, portfolio_pct SHALL be exactly 0.
|
||||
|
||||
**Validates: Requirements 14.4, 14.7, 21.8, 21.9**
|
||||
|
||||
### Property 12: Posterior state JSON round-trip
|
||||
|
||||
*For any* valid V3Posterior state (p_up, log_odds, strength, confidence, contradiction, n_eff, data_quality, regime), serializing to JSON and deserializing SHALL produce an equivalent state within floating-point tolerance (1e-10).
|
||||
|
||||
**Validates: Requirements 20.1, 21.10**
|
||||
|
||||
### Property 13: Noisy-OR normalized exposure is bounded in [0, 1]
|
||||
|
||||
*For any* overlap values O_k in [0, 1] for each dimension (geo, supply, commodity, sector) with fixed positive weights, the normalized macro exposure E_macro SHALL be in [0.0, 1.0], reaching exactly 1.0 when all O_k = 1.0.
|
||||
|
||||
**Validates: Requirements 9.1, 9.2**
|
||||
|
||||
### Property 14: Competitive LLR is clamped to [-1.25, 1.25]
|
||||
|
||||
*For any* source LLR, shrunk correlation (non-negative), graph distance (1-3), and pattern confidence in [0,1], the computed competitive LLR SHALL be in [-1.25, 1.25].
|
||||
|
||||
**Validates: Requirements 10.4, 10.5**
|
||||
|
||||
### Property 15: Graph attenuation is zero beyond max distance
|
||||
|
||||
*For any* inputs where graph distance > 3, the computed attenuation SHALL be 0.0, producing zero competitive LLR regardless of other parameters.
|
||||
|
||||
**Validates: Requirements 10.3**
|
||||
|
||||
### Property 16: Projection evidence state decays toward zero
|
||||
|
||||
*For any* initial evidence state A_t and regime decay phi in (0, 1), the projected state A_projected_h = phi^h * A_t SHALL have |A_projected_h| < |A_t| for all h >= 1, converging toward 0 as h increases.
|
||||
|
||||
**Validates: Requirements 11.1, 11.3**
|
||||
|
||||
### Property 17: Data quality score is bounded in [0, 1]
|
||||
|
||||
*For any* valid inputs (extraction_failure_rate in [0,1], extraction_conf_i in [0,1], impact_i in [0,1], age_newest_hours >= 0, N_valid >= 0, N_source_types >= 0), the computed data_quality_score SHALL be in [0, 1].
|
||||
|
||||
**Validates: Requirements 17.6**
|
||||
|
||||
### Property 18: Stop loss is below entry price and take profit is above
|
||||
|
||||
*For any* entry_price > 0, stop_distance_pct in [0.005, 1.0), and reward ratio b >= 1.2, the computed stop_loss SHALL be less than entry_price and take_profit SHALL be greater than entry_price.
|
||||
|
||||
**Validates: Requirements 16.2, 16.3**
|
||||
|
||||
### Property 19: Trailing stop never decreases
|
||||
|
||||
*For any* sequence of current prices and trailing stop computations, each new trailing_stop value SHALL be >= the previous trailing_stop value (monotonically non-decreasing).
|
||||
|
||||
**Validates: Requirements 16.5**
|
||||
|
||||
### Property 20: Regime classification is exhaustive and deterministic
|
||||
|
||||
*For any* valid market data inputs (closing_prices of sufficient length, daily_returns, ATR_20 > 0), the regime classification SHALL produce exactly one of {panic, trend_following, mean_reversion, uncertainty} and the same inputs SHALL always produce the same classification.
|
||||
|
||||
**Validates: Requirements 6.2, 6.3, 6.4, 6.5**
|
||||
|
||||
### Property 21: EvidenceUnit normalization preserves field ranges
|
||||
|
||||
*For any* valid company, macro, or competitive signal input, the normalized EvidenceUnit SHALL have: direction in {-1, 0, +1}, sentiment_strength in [0, 1], impact in [0, 1], extraction_conf in [0, 1], source_cred in [0, 1], novelty in [0, 1], and event_base_rate in (0, 1].
|
||||
|
||||
**Validates: Requirements 1.1, 1.2, 1.3, 1.4, 1.7**
|
||||
|
||||
### Property 22: Portfolio heat rejection is correct
|
||||
|
||||
*For any* set of open positions with stop distances, if the sum of (position_value × stop_distance_pct) exceeds max_portfolio_heat × portfolio_value, then new position entry SHALL be rejected.
|
||||
|
||||
**Validates: Requirements 15.3, 15.5**
|
||||
|
||||
### Property 23: Tier auto-adjustment obeys downgrade-any, upgrade-all logic
|
||||
|
||||
*For any* TierMetrics, if ANY single downgrade condition is met (profit_factor < 1.0 OR drawdown > 0.12 OR calibration_error > 0.20 OR sharpe < 0), the result SHALL be "downgrade". An "upgrade" SHALL only occur when ALL upgrade conditions are simultaneously met.
|
||||
|
||||
**Validates: Requirements 18.3, 18.4**
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Fail-Closed Philosophy
|
||||
|
||||
The v3 engine follows a fail-closed design: when in doubt, suppress the trade rather than emit a false signal.
|
||||
|
||||
| Error Scenario | Response | Fallback |
|
||||
|---|---|---|
|
||||
| `v3_engine_enabled` flag unreadable | Default to heuristic mode | Log warning |
|
||||
| Unhandled exception in v3 pipeline | Fall back to heuristic for that cycle | Log ERROR with traceback, record in metadata |
|
||||
| Missing market data for regime | Default to "uncertainty" regime | Most conservative multipliers |
|
||||
| Missing source statistics | q_source = 0.0 (neutral prior) | Source treated as untrusted |
|
||||
| Missing realized_vol_20d | Use default 0.25 annualized | Conservative volatility estimate |
|
||||
| Division by zero in n_eff | Return n_eff = 1.0 (single signal) | Denominator guard |
|
||||
| NaN/Inf in any computation | Clamp to boundary, log warning | Never propagate NaN to output |
|
||||
| data_quality < 0.50 | Force informational mode | Suppress trade recommendation |
|
||||
| No company evidence (only macro/competitive) | Force informational | Unless macro_only_enabled |
|
||||
|
||||
### Numerical Guards
|
||||
|
||||
All mathematical functions include:
|
||||
- **Sigmoid overflow**: Guard `exp(-x)` for x > 500 or x < -500
|
||||
- **Log domain**: Guard `log(x)` with x > 0 check; `log2(0)` treated as 0 in entropy
|
||||
- **Division by zero**: All denominators checked > 0 before division
|
||||
- **NaN propagation**: All outputs validated with `math.isnan()` check before storage
|
||||
- **Clamp boundaries**: Final values clamped to documented ranges
|
||||
|
||||
### Graceful Degradation Chain
|
||||
|
||||
```
|
||||
v3 pipeline error → heuristic fallback → informational mode → no recommendation
|
||||
```
|
||||
|
||||
Each level preserves audit trail via output metadata.
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Dual Testing Approach
|
||||
|
||||
**Property-Based Tests (Hypothesis):**
|
||||
- Library: `hypothesis` (already in use in this project)
|
||||
- Configuration: `@settings(max_examples=100)` minimum per property
|
||||
- File naming: `tests/test_pbt_v3_*.py`
|
||||
- Each property test tagged with: `# Feature: math-core-v3-engine, Property N: <title>`
|
||||
- One property-based test per correctness property (23 properties → 23 PBT tests)
|
||||
|
||||
**Unit Tests (pytest):**
|
||||
- Specific examples with known inputs/outputs for each formula
|
||||
- Edge cases: zero inputs, boundary values, NaN handling
|
||||
- Integration between components (e.g., full pipeline from EvidenceUnit to recommendation)
|
||||
- Error handling paths (DB errors, missing data, feature flag states)
|
||||
|
||||
### Property Test Organization
|
||||
|
||||
| Test File | Properties Covered | Module Under Test |
|
||||
|---|---|---|
|
||||
| `tests/test_pbt_v3_reliability.py` | 1, 2, 3, 4, 21 | scoring.py (q_i, p_correct, LLR) |
|
||||
| `tests/test_pbt_v3_clustering.py` | 5, 6 | worker.py (n_eff, cluster LLR) |
|
||||
| `tests/test_pbt_v3_posterior.py` | 7, 8, 9, 10, 12, 20 | bayesian.py, contradiction.py, worker.py |
|
||||
| `tests/test_pbt_v3_layers.py` | 13, 14, 15 | interpolation.py, signal_propagation.py |
|
||||
| `tests/test_pbt_v3_projection.py` | 16 | projection.py |
|
||||
| `tests/test_pbt_v3_decision.py` | 11, 17, 18, 19, 22 | position_sizer.py, stop_loss_manager.py, eligibility.py |
|
||||
| `tests/test_pbt_v3_tier.py` | 23 | risk/engine.py |
|
||||
|
||||
### Hypothesis Strategy Design
|
||||
|
||||
Key custom strategies for generating valid inputs:
|
||||
|
||||
```python
|
||||
from hypothesis import strategies as st
|
||||
|
||||
# EvidenceUnit generator
|
||||
evidence_units = st.builds(
|
||||
EvidenceUnit,
|
||||
symbol=st.text(min_size=1, max_size=5),
|
||||
layer=st.sampled_from(["company", "macro", "competitive"]),
|
||||
direction=st.sampled_from([-1, 0, 1]),
|
||||
sentiment_strength=st.floats(min_value=0.0, max_value=1.0),
|
||||
impact=st.floats(min_value=0.0, max_value=1.0),
|
||||
extraction_conf=st.floats(min_value=0.0, max_value=1.0),
|
||||
source_cred=st.floats(min_value=0.0, max_value=1.0),
|
||||
novelty=st.floats(min_value=0.0, max_value=1.0),
|
||||
event_base_rate=st.floats(min_value=0.01, max_value=1.0),
|
||||
...
|
||||
)
|
||||
|
||||
# Cluster LLR list generator
|
||||
cluster_llrs = st.lists(
|
||||
st.floats(min_value=-2.5, max_value=2.5),
|
||||
min_size=1, max_size=20,
|
||||
)
|
||||
|
||||
# Regime generator
|
||||
regimes = st.sampled_from(["panic", "trend_following", "mean_reversion", "uncertainty"])
|
||||
```
|
||||
|
||||
### Unit Test Coverage
|
||||
|
||||
| Area | Key Example Tests |
|
||||
|---|---|
|
||||
| EvidenceUnit normalization | Company signal → correct fields; macro → correct horizon mapping |
|
||||
| q_i pipeline | Known inputs → known outputs for each sub-formula |
|
||||
| LLR conversion | p_correct=0.60 → LLR≈0.405; direction=-1 → negative LLR |
|
||||
| Clustering | 3 identical articles → n_eff < 3; independent → n_eff = N |
|
||||
| Posterior | Empty evidence → P_up=0.50; strong bullish → P_up > 0.60 |
|
||||
| Contradiction | All bullish → 0; equal split → high score |
|
||||
| Confidence | Zero data quality → near-zero confidence |
|
||||
| Macro LLR | Full exposure → max LLR ≈ 1.10; zero overlap → LLR ≈ 0 |
|
||||
| Competitive | Distance 4 → zero propagation; direct rival → attenuated signal |
|
||||
| Kelly sizing | p_win=0.3, b=2 → f_kelly < 0 → size = 0 |
|
||||
| Stops | Entry=100, stop_dist=0.02 → stop=98, TP > 100 |
|
||||
| Feature flag | Flag false → heuristic path; flag true → v3 path |
|
||||
| Error fallback | v3 raises → heuristic runs, error logged |
|
||||
|
||||
### Integration Tests
|
||||
|
||||
- Full pipeline: raw signals → EvidenceUnit → q_i → LLR → cluster → posterior → recommendation
|
||||
- Feature flag toggle: verify clean switch between pipelines mid-run
|
||||
- JSONB round-trip: store v3 output in PostgreSQL JSONB, retrieve and verify
|
||||
- Regime transitions: price series that crosses regime boundaries
|
||||
@@ -0,0 +1,314 @@
|
||||
# Requirements Document
|
||||
|
||||
## Introduction
|
||||
|
||||
This specification defines the requirements for upgrading the Stonks Oracle signal processing engine from the current dual-mode pipeline (heuristic + probabilistic) to the v3 Calibrated Evidence Engine. The v3 engine replaces arbitrary weighted-sentiment scoring with a principled probabilistic pipeline: calibrated reliability estimation, log-likelihood ratio (LLR) evidence accumulation, correlation-aware clustering, Bayesian posterior assembly, return distribution modeling, and Kelly-criterion position sizing. The upgrade preserves the existing three-layer architecture (company, macro, competitive), the WeightedSignal abstraction, database schema compatibility, and the service boundary structure. The entire v3 engine operates behind a `v3_engine_enabled` feature flag with the heuristic mode retained as a fallback.
|
||||
|
||||
## Glossary
|
||||
|
||||
- **V3_Engine**: The new calibrated evidence engine that replaces the current heuristic and probabilistic scoring modes
|
||||
- **EvidenceUnit**: The canonical normalized shape for all signals (company, macro, competitive) before aggregation
|
||||
- **LLR**: Log-Likelihood Ratio — the calibrated evidence contribution of a single signal or cluster, measured in log-odds units
|
||||
- **Cluster**: A group of correlated signals sharing (symbol, horizon, event_type, source_group, time_bucket)
|
||||
- **n_eff**: Effective evidence count within a cluster after de-correlation adjustment
|
||||
- **Posterior**: The Bayesian posterior probability P_up computed via log-odds accumulation
|
||||
- **Regime**: Market regime classification (panic, trend_following, mean_reversion, uncertainty) derived from EMA trend and volatility indicators
|
||||
- **Contradiction_Score**: A measure of opposing evidence based on LLR entropy and evidence volume
|
||||
- **Data_Quality_Score**: Multiplicative fail-closed quality metric combining parse rate, confidence, freshness, coverage, and diversity
|
||||
- **Fractional_Kelly**: Position sizing method using Kelly criterion scaled by a conservative fraction (0.25) and further modulated by confidence, data quality, and contradiction
|
||||
- **Portfolio_Heat**: Total stop-defined risk dollars across all open positions as a fraction of portfolio value
|
||||
- **Feature_Flag**: The `v3_engine_enabled` runtime toggle that activates the v3 pipeline without code deployment
|
||||
- **Scoring_Service**: The `services/aggregation/scoring.py` module responsible for signal weight computation
|
||||
- **Bayesian_Service**: The `services/aggregation/bayesian.py` module responsible for posterior computation
|
||||
- **Contradiction_Service**: The `services/aggregation/contradiction.py` module responsible for conflict detection
|
||||
- **Regime_Service**: The `services/aggregation/regime.py` module responsible for market regime classification
|
||||
- **Projection_Service**: The `services/aggregation/projection.py` module responsible for trend projection
|
||||
- **Eligibility_Service**: The `services/recommendation/eligibility.py` module responsible for recommendation gating
|
||||
- **Position_Sizer**: The `services/trading/position_sizer.py` module responsible for trade sizing
|
||||
- **Stop_Loss_Manager**: The `services/trading/stop_loss_manager.py` module responsible for stop/TP computation
|
||||
- **Risk_Engine**: The `services/risk/engine.py` module responsible for portfolio risk enforcement
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement 1: Canonical Evidence Unit Normalization
|
||||
|
||||
**User Story:** As the aggregation engine, I want all signals normalized into a canonical EvidenceUnit shape, so that company, macro, and competitive signals flow through a single unified pipeline.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN a company signal is received, THE V3_Engine SHALL normalize the signal into an EvidenceUnit containing symbol, layer (set to "company"), event_type, source_id, source_group, timestamp, horizon (one of: intraday, 1d, 7d, 30d, 90d), direction (-1/0/+1), sentiment_strength [0,1], impact [0,1], extraction_conf [0,1], source_cred [0,1], novelty [0,1], event_base_rate (float in (0.0, 1.0]), and cluster_id
|
||||
2. WHEN a macro signal is received, THE V3_Engine SHALL normalize the signal into an EvidenceUnit with layer set to "macro", symbol mapped from the macro impact record's ticker, direction mapped from impact_direction (positive→+1, negative→-1, neutral→0), impact mapped from macro_impact_score, source_cred mapped from event confidence, extraction_conf mapped from event confidence, novelty set to 1.0 for new events, source_id mapped from the global event id, source_group set to "macro", and horizon derived from the event's estimated_duration (short_term→7d, medium_term→30d, long_term→90d)
|
||||
3. WHEN a competitive signal is received, THE V3_Engine SHALL normalize the signal into an EvidenceUnit with layer set to "competitive", symbol set to the target ticker, direction mapped from signal_direction (bullish→+1, bearish→-1, neutral→0), impact mapped from signal_strength × relationship_strength, source_cred mapped from pattern_confidence, extraction_conf set to pattern_confidence, novelty set to 1.0, source_id mapped from source_document_id, source_group set to "competitive", and horizon derived from the pattern's time_horizon field
|
||||
4. THE V3_Engine SHALL assign direction value of +1 for signals with sentiment or impact_direction equal to "positive" or "bullish", -1 for "negative" or "bearish", and 0 for "neutral" or "mixed"
|
||||
5. WHEN a signal has direction equal to 0 (neutral), THE V3_Engine SHALL include the signal in quality, coverage, and contradiction context computations but SHALL exclude the signal from directional posterior voting
|
||||
6. IF a required source field (symbol, timestamp, or source_id) is missing or null in the incoming signal, THEN THE V3_Engine SHALL reject the signal, log a warning identifying the signal source and missing field, and not produce an EvidenceUnit for that signal
|
||||
7. IF an optional numeric field (sentiment_strength, impact, extraction_conf, source_cred, novelty) is missing or null, THEN THE V3_Engine SHALL substitute a default value of 0.5 for the missing field
|
||||
8. THE V3_Engine SHALL assign event_base_rate from a configured lookup by event_type, defaulting to 0.10 when no event_type-specific base rate is configured
|
||||
|
||||
### Requirement 2: Calibrated Reliability Computation
|
||||
|
||||
**User Story:** As the scoring engine, I want to compute a calibrated reliability q_i for each signal, so that evidence quality is measured probabilistically instead of via arbitrary weight products.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Scoring_Service SHALL compute extraction reliability as q_ext = sigmoid(k_ext × (extraction_conf - m_ext)) with defaults k_ext = 8.0 and m_ext = 0.55, where extraction_conf is in [0.0, 1.0] and q_ext output is in (0.0, 1.0)
|
||||
2. THE Scoring_Service SHALL compute source reliability using Bayesian shrinkage: E[theta_s] = (alpha_0 + hits_s) / (alpha_0 + beta_0 + hits_s + misses_s) with defaults alpha_0 = 3, beta_0 = 3, and q_source = clamp((E[theta_s] - 0.50) / 0.35, 0.0, 1.0), where hits_s and misses_s are non-negative integers representing the source's historical correct and incorrect directional predictions
|
||||
3. IF a source has zero historical outcomes (hits_s = 0 AND misses_s = 0), THEN THE Scoring_Service SHALL compute q_source = 0.0 from the prior (E[theta_s] = 0.5)
|
||||
4. THE Scoring_Service SHALL compute recency reliability as q_recency = 2^(-age_hours / tau_adaptive) where tau_adaptive = tau_base × (1 + 0.75 × impact + 0.50 × surprise) and surprise = clamp(-log2(event_base_rate) / 5, 0, 1), with age_hours = max((reference_time - signal_timestamp).total_seconds() / 3600, 0.0)
|
||||
5. IF event_base_rate is unavailable or equal to zero, THEN THE Scoring_Service SHALL use a default event_base_rate of 0.10 to prevent undefined logarithm computation
|
||||
6. THE Scoring_Service SHALL use horizon-specific half-life defaults: intraday=2h, 1d=12h, 7d=72h, 30d=240h, 90d=720h
|
||||
7. THE Scoring_Service SHALL compute uniqueness as q_uniqueness = clamp(0.50 + 0.50 × novelty, 0.50, 1.00) × (1 / sqrt(1 + duplicate_count_before)), where duplicate_count_before is the number of other signals in the same cluster that were ingested before this signal
|
||||
8. THE Scoring_Service SHALL compute final signal reliability as q_i = clamp(q_ext × q_source × source_cred × q_recency × q_uniqueness, 0.0, 1.0)
|
||||
9. WHEN q_recency falls below 0.01, THE Scoring_Service SHALL apply a floor of 0.01 only for explainability display output and SHALL use the unmodified q_recency value (including zero) for posterior voting computation
|
||||
|
||||
### Requirement 3: Log-Likelihood Ratio Conversion
|
||||
|
||||
**User Story:** As the posterior engine, I want signals converted to calibrated log-likelihood ratios, so that evidence accumulation follows proper Bayesian updating rules.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Scoring_Service SHALL compute directional correctness probability as p_correct = clamp(0.50 + 0.35 × q_i × impact × sentiment_strength, 0.501, 0.85)
|
||||
2. THE Scoring_Service SHALL compute the signal log-likelihood ratio as LLR_i = direction × ln(p_correct / (1 - p_correct)), where ln denotes the natural logarithm (base e), consistent with the logit function used in posterior assembly
|
||||
3. WHEN direction equals 0 (neutral signal), THE Scoring_Service SHALL produce LLR_i = 0.0, excluding the signal from directional posterior voting while retaining it for quality and contradiction context
|
||||
4. THE Scoring_Service SHALL clamp p_correct to a minimum of 0.501 to ensure LLR_i is always nonzero for directional signals (direction ≠ 0), producing a minimum absolute LLR magnitude of approximately 0.004
|
||||
5. THE Scoring_Service SHALL clamp p_correct to a maximum of 0.85 to prevent any single signal from dominating the posterior, producing a maximum absolute LLR magnitude of approximately 1.735
|
||||
6. FOR ALL valid directional signals (direction ∈ {-1, +1}), THE Scoring_Service SHALL produce LLR_i values with the same sign as direction
|
||||
|
||||
### Requirement 4: Correlation-Aware Evidence Clustering
|
||||
|
||||
**User Story:** As the aggregation engine, I want correlated signals grouped and de-duplicated before posterior assembly, so that near-identical articles cannot inflate evidence counts.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE V3_Engine SHALL cluster signals by (symbol, horizon, event_type, source_group, time_bucket)
|
||||
2. THE V3_Engine SHALL compute effective evidence count as n_eff_c = (sum_i w_i)^2 / (sum_i w_i^2 + 2 × sum_{i<j}(rho_ij × w_i × w_j)) where w_i = abs(LLR_i)
|
||||
3. THE V3_Engine SHALL use default pairwise correlations: rho=0.80 for same wire/story/source group, rho=0.50 for same event different publisher, rho=0.25 for same theme different event, rho=0.00 for independent events
|
||||
4. THE V3_Engine SHALL compute cluster LLR as LLR_c = weighted_mean(LLR_i, abs(LLR_i)) × sqrt(n_eff_c)
|
||||
5. THE V3_Engine SHALL clamp each cluster LLR to the range [-2.5, 2.5] to prevent any single cluster from dominating the posterior
|
||||
|
||||
### Requirement 5: Posterior Assembly via Log-Odds
|
||||
|
||||
**User Story:** As the Bayesian engine, I want to assemble a posterior probability from cluster LLRs and a regime-aware prior, so that the trading decision is based on calibrated belief.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Bayesian_Service SHALL use a neutral base prior of P_prior = 0.50 unless a calibrated symbol/sector prior is stored in the risk_configs table for the given ticker or its sector
|
||||
2. THE Bayesian_Service SHALL compute posterior log-odds as logit(P_up) = logit(P_prior) + sum_c(gamma_regime × LLR_c) where gamma_regime is the regime evidence multiplier from Requirement 6 criterion 6
|
||||
3. THE Bayesian_Service SHALL compute P_up = sigmoid(logit(P_up)) = 1/(1+exp(-logit(P_up))) and P_down = 1 - P_up, clamping P_up to the range [1e-10, 1 - 1e-10] to avoid numerical boundary issues
|
||||
4. THE Bayesian_Service SHALL compute trend strength as strength = abs(2 × P_up - 1), producing a value in [0.0, 1.0] where 0.0 indicates maximum uncertainty and 1.0 indicates maximum directional conviction
|
||||
5. THE Bayesian_Service SHALL apply regime-specific direction thresholds to classify direction from P_up: panic (bullish when P_up >= 0.68, bearish when P_up <= 0.32), trend_following (bullish when P_up >= 0.60, bearish when P_up <= 0.40), mean_reversion (bullish when P_up >= 0.63, bearish when P_up <= 0.37), uncertainty (bullish when P_up >= 0.65, bearish when P_up <= 0.35). WHEN P_up falls between the bullish and bearish thresholds, THE Bayesian_Service SHALL classify direction as neutral
|
||||
6. WHEN P_prior is calibrated from the risk_configs table, THE Bayesian_Service SHALL clamp P_prior to the range [0.40, 0.60] before computing logit(P_prior)
|
||||
7. IF the risk_configs lookup for a calibrated prior fails due to a database error, THEN THE Bayesian_Service SHALL fall back to the neutral base prior of 0.50 and log a warning
|
||||
|
||||
### Requirement 6: Regime Detection v3
|
||||
|
||||
**User Story:** As the regime service, I want to classify market regimes using z-scored indicators and apply regime-appropriate evidence multipliers, so that the engine adapts its sensitivity to market conditions.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Regime_Service SHALL compute trend_z = (EMA_20 - EMA_100) / ATR_20 where EMA_20 and EMA_100 are exponential moving averages of closing prices, and ATR_20 is the 20-day Average True Range. THE Regime_Service SHALL compute vol_ratio = sigma_20 / sigma_100 where sigma_20 and sigma_100 are standard deviations of daily returns
|
||||
2. THE Regime_Service SHALL classify panic when vol_ratio > 1.5 OR abs(trend_z) > 2.5. Panic classification SHALL take priority over all other regimes
|
||||
3. IF the regime is not panic, THEN THE Regime_Service SHALL classify trend_following when abs(trend_z) >= 0.75 AND vol_ratio < 1.3
|
||||
4. IF the regime is neither panic nor trend_following, THEN THE Regime_Service SHALL classify mean_reversion when abs(trend_z) < 0.50 AND vol_ratio < 1.0
|
||||
5. THE Regime_Service SHALL classify uncertainty for all conditions not matching panic, trend_following, or mean_reversion
|
||||
6. THE Regime_Service SHALL apply regime evidence multipliers (gamma_regime): panic=0.70, trend_following=1.10, mean_reversion=0.90, uncertainty=0.80
|
||||
7. THE Regime_Service SHALL apply regime confidence multipliers: panic=0.70, trend_following=1.00, mean_reversion=0.95, uncertainty=0.85
|
||||
8. IF market data is insufficient to compute EMA_100 (fewer than 100 closing prices) or ATR_20 (fewer than 20 bars) or sigma_100 (fewer than 100 daily returns), THEN THE Regime_Service SHALL default to the uncertainty regime
|
||||
|
||||
### Requirement 7: LLR Entropy Contradiction
|
||||
|
||||
**User Story:** As the contradiction service, I want to measure meaningful opposing evidence using LLR entropy, so that contradiction reflects genuine disagreement scaled by evidence volume.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Contradiction_Service SHALL compute E_pos = sum_c(max(LLR_c, 0)) and E_neg = sum_c(max(-LLR_c, 0)) and E_total = E_pos + E_neg
|
||||
2. WHEN E_total equals zero (no directional evidence from any cluster), THE Contradiction_Service SHALL return a contradiction score of 0.0
|
||||
3. WHEN E_total is greater than zero, THE Contradiction_Service SHALL compute f_pos = E_pos / E_total and f_neg = E_neg / E_total where f_pos + f_neg = 1.0
|
||||
4. THE Contradiction_Service SHALL compute H_conflict = -f_pos × log2(f_pos) - f_neg × log2(f_neg), treating 0 × log2(0) as 0 for the boundary case. H_conflict ranges from 0.0 (all one direction) to 1.0 (equal split)
|
||||
5. THE Contradiction_Service SHALL compute volume_factor = 1 - exp(-E_total / 3.0), where 3.0 represents the evidence mass at which contradiction becomes 95% significant
|
||||
6. THE Contradiction_Service SHALL compute the final contradiction score as H_conflict × volume_factor, producing a value in [0.0, 1.0]
|
||||
7. WHEN only one direction of evidence exists (E_pos = 0 or E_neg = 0 but E_total > 0), THE Contradiction_Service SHALL return a contradiction score of 0.0
|
||||
|
||||
### Requirement 8: Multiplicative Confidence v3
|
||||
|
||||
**User Story:** As the aggregation engine, I want confidence computed multiplicatively from independent quality dimensions, so that one weak dimension suppresses the trade rather than being averaged away.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE V3_Engine SHALL compute C_evidence = 1 - exp(-n_eff_total / 5.0) where n_eff_total = sum_c(n_eff_c)
|
||||
2. THE V3_Engine SHALL compute C_quality = weighted_mean(q_i, weight=abs(LLR_i))
|
||||
3. THE V3_Engine SHALL compute confidence = clamp(C_evidence × sqrt(C_quality) × sqrt(max(strength, 0.05)) × regime_confidence_multiplier × (1 - contradiction) × data_quality_score, 0, 1)
|
||||
4. THE V3_Engine SHALL use strength = abs(2 × P_up - 1) as the directional separation term
|
||||
5. WHEN any single confidence dimension is near zero, THE V3_Engine SHALL produce a near-zero final confidence due to the multiplicative formula
|
||||
|
||||
### Requirement 9: Macro Layer v3 (Noisy-OR Exposure)
|
||||
|
||||
**User Story:** As the macro interpolation service, I want to compute normalized exposure via noisy-OR and emit macro evidence as LLR into the shared posterior, so that macro signals integrate with company evidence without special post-hoc modifiers.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE V3_Engine SHALL compute macro exposure as E_raw = 1 - product_k(1 - w_k × O_k) with default weights w_geo=0.35, w_supply=0.25, w_commodity=0.25, w_sector=0.15
|
||||
2. THE V3_Engine SHALL normalize macro exposure as E_macro = E_raw / E_max where E_max = 1 - product_k(1 - w_k)
|
||||
3. THE V3_Engine SHALL apply resilience dampener per market position tier: global_leader=0.70, multinational=0.85, regional=1.00, domestic=1.20
|
||||
4. THE V3_Engine SHALL compute macro likelihood ratio as LLR_macro = macro_direction × log(p_macro / (1 - p_macro)) where p_macro = clamp(0.50 + 0.30 × macro_impact × event_confidence × q_recency, 0.501, 0.80)
|
||||
5. THE V3_Engine SHALL feed macro LLR into the same posterior engine as company evidence without requiring a separate post-hoc modifier
|
||||
|
||||
### Requirement 10: Competitive Layer v3 (Correlation-Shrunk Propagation)
|
||||
|
||||
**User Story:** As the signal propagation service, I want to use correlation-shrunk attenuation for competitive signals, so that propagated evidence is properly discounted by distance and relationship strength.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE V3_Engine SHALL compute shrunk correlation as rho_shrunk = (n / (n + 30)) × rho_rolling + (30 / (n + 30)) × rho_prior with rho_prior_same_sector = 0.30 and rho_prior_cross_sector = 0.10
|
||||
2. THE V3_Engine SHALL compute rho_effective = max(rho_shrunk, 0) to use only positive propagation unless the relationship is explicitly inverse
|
||||
3. THE V3_Engine SHALL compute graph attenuation as attenuation = rho_effective × exp(-0.85 × d_network) with max_distance = 3
|
||||
4. THE V3_Engine SHALL compute competitive LLR as LLR_competitive = LLR_source × attenuation × pattern_confidence
|
||||
5. THE V3_Engine SHALL clamp competitive LLR to the range [-1.25, 1.25] to prevent competitive signals from dominating the posterior
|
||||
|
||||
### Requirement 11: Trend Projection v3 (Posterior State)
|
||||
|
||||
**User Story:** As the projection service, I want to project trends using a posterior state with regime-aware decay, so that projections are grounded in the same Bayesian framework as current estimates.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Projection_Service SHALL maintain an evidence state A_t = phi_regime × A_{t-1} + sum_c(LLR_c), initialized to A_0 = 0.0 when no prior state exists for a ticker-horizon pair
|
||||
2. THE Projection_Service SHALL use regime-specific decay factors: panic phi=0.35, trend_following phi=0.80, mean_reversion phi=0.55, uncertainty phi=0.50
|
||||
3. THE Projection_Service SHALL compute projected alpha as A_projected_h = phi_regime^h × A_t + expected_known_catalyst_LLR_h, where h is the projection horizon in aggregation cycles and expected_known_catalyst_LLR_h defaults to 0.0 when no known catalysts exist
|
||||
4. THE Projection_Service SHALL compute projected probability as P_up_projected_h = sigmoid(logit(P_prior_h) + A_projected_h)
|
||||
5. THE Projection_Service SHALL compute projected strength as abs(2 × P_up_projected_h - 1)
|
||||
6. THE Projection_Service SHALL flag divergence when sign(P_up_projected_h - 0.5) differs from sign(P_up_t - 0.5)
|
||||
7. WHEN market data is insufficient for regime classification, THE Projection_Service SHALL use the uncertainty decay factor (phi=0.50) as the default
|
||||
|
||||
### Requirement 12: Return Distribution and Expected Value Gate
|
||||
|
||||
**User Story:** As the eligibility service, I want to gate recommendations using a return distribution model, so that only trades with positive risk-adjusted expected value pass through.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Eligibility_Service SHALL compute horizon volatility as sigma_h = realized_vol_20d × sqrt(horizon_days / 252), where horizon_days maps to 1 (intraday/1d), 7 (7d), 30 (30d), or 90 (90d)
|
||||
2. THE Eligibility_Service SHALL compute expected return as mu_h = tanh(A_projected_h / 3.0) × confidence × sigma_h
|
||||
3. THE Eligibility_Service SHALL compute EV_long = mu_h - costs - 0.10 × CVaR_5_loss, where costs = spread_cost + slippage_estimate + commission_estimate, and CVaR_5_loss = sigma_h × 1.645 × 1.4 (Gaussian approximation of expected loss beyond the 5th percentile)
|
||||
4. THE Eligibility_Service SHALL compute regime-specific minimum edge: panic=0.0100, trend_following=0.0035, mean_reversion=0.0050, uncertainty=0.0075
|
||||
5. THE Eligibility_Service SHALL require EV_long > min_edge AND EV_long > max(0.0025, 0.25 × costs) for trade eligibility
|
||||
6. THE Eligibility_Service SHALL require confidence >= regime_confidence_min AND contradiction <= regime_contradiction_max AND n_eff_total >= 2.0 AND data_quality_score >= 0.50 for eligibility
|
||||
7. IF realized_vol_20d is unavailable (fewer than 20 trading days of price data), THEN THE Eligibility_Service SHALL use a default volatility of 0.25 (annualized) for sigma_h computation
|
||||
|
||||
### Requirement 13: Recommendation Eligibility and Mode Escalation v3
|
||||
|
||||
**User Story:** As the recommendation service, I want regime-aware eligibility gates and mode escalation, so that recommendation quality matches the rigor of the v3 posterior.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Eligibility_Service SHALL apply regime-specific eligibility thresholds: panic (confidence_min=0.70, contradiction_max=0.25, strength_min=0.36), trend_following (confidence_min=0.55, contradiction_max=0.40, strength_min=0.20), mean_reversion (confidence_min=0.60, contradiction_max=0.35, strength_min=0.26), uncertainty (confidence_min=0.65, contradiction_max=0.30, strength_min=0.30)
|
||||
2. THE Eligibility_Service SHALL map action as BUY when P_up >= bullish_threshold and EV_long > min_edge, SELL when existing position and EV_exit > EV_hold, HOLD when existing position, and WATCH otherwise
|
||||
3. THE Eligibility_Service SHALL escalate to live_eligible when action is BUY or SELL and confidence >= 0.75 and contradiction <= 0.20 and n_eff_total >= 5 and EV_long > 2 × min_edge and risk_engine_passed
|
||||
4. THE Eligibility_Service SHALL escalate to paper_eligible when action is BUY or SELL and confidence >= 0.60 and EV_long > min_edge and risk_engine_passed
|
||||
5. IF eligibility gates are not met, THEN THE Eligibility_Service SHALL assign mode as informational
|
||||
|
||||
### Requirement 14: Fractional Kelly Position Sizing
|
||||
|
||||
**User Story:** As the position sizer, I want to size positions using fractional Kelly criterion, so that position sizes are proportional to edge and constrained by risk.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Position_Sizer SHALL compute stop_distance_pct = max(ATR_pct × ATR_multiplier_regime, sigma_h × 1.25, 0.005) where ATR_pct = ATR_14 / current_price, with regime ATR multipliers: panic=2.5, trend_following=1.8, mean_reversion=1.4, uncertainty=2.0
|
||||
2. THE Position_Sizer SHALL compute reward ratio b = clamp(1.2 + 2.0 × confidence + 1.0 × strength - contradiction, 1.2, 3.0)
|
||||
3. THE Position_Sizer SHALL compute f_kelly = (p_win × b - (1 - p_win)) / b where p_win = P_up from the Bayesian posterior
|
||||
4. THE Position_Sizer SHALL compute final sizing as portfolio_pct = clamp(max(0, f_kelly) × 0.25 × confidence × data_quality_score × (1 - contradiction), 0, max_position_pct)
|
||||
5. THE Position_Sizer SHALL enforce hard caps by reducing portfolio_pct to the minimum of: max_position_pct from the active risk tier, available_sector_capacity_pct, available_correlation_capacity_pct (0 if weighted average absolute correlation with existing positions exceeds 0.80), and available_heat_capacity_pct
|
||||
6. IF portfolio_pct after all caps is less than 0.005 (0.5% of portfolio), THEN THE Position_Sizer SHALL downgrade the recommendation to WATCH with reason "position_below_minimum"
|
||||
7. IF f_kelly is less than or equal to zero, THEN THE Position_Sizer SHALL produce portfolio_pct = 0 and downgrade the recommendation to WATCH with reason "negative_edge"
|
||||
|
||||
### Requirement 15: Stop-Defined Portfolio Heat
|
||||
|
||||
**User Story:** As the risk engine, I want portfolio heat calculated from stop-defined risk dollars, so that risk measurement reflects actual loss exposure rather than position notional.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Risk_Engine SHALL compute risk_dollars = position_value × stop_distance_pct for each open position
|
||||
2. THE Risk_Engine SHALL compute portfolio_heat = sum of risk_dollars across all open positions
|
||||
3. IF portfolio_heat exceeds max_portfolio_heat × portfolio_value, THEN THE Risk_Engine SHALL reject new position entries
|
||||
4. THE Position_Sizer SHALL compute available_heat_capacity = max_portfolio_heat × portfolio_value - current_portfolio_heat
|
||||
5. THE Position_Sizer SHALL reject a position when the new risk_dollars would exceed available_heat_capacity
|
||||
|
||||
### Requirement 16: Regime-Aware Stop Loss and Take Profit
|
||||
|
||||
**User Story:** As the stop loss manager, I want stops and targets computed from regime-aware volatility and dynamic reward ratios, so that exit levels adapt to current market conditions.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Stop_Loss_Manager SHALL compute stop_distance_pct = max(ATR_pct × regime_ATR_multiplier, sigma_h × z_stop, min_stop_pct) with z_stop = 1.25 and min_stop_pct = 0.005
|
||||
2. THE Stop_Loss_Manager SHALL compute stop_loss = entry_price × (1 - stop_distance_pct) for long positions
|
||||
3. THE Stop_Loss_Manager SHALL compute take_profit = entry_price × (1 + b × stop_distance_pct) where b = clamp(1.2 + 2.0 × confidence + 1.0 × strength - contradiction, 1.2, 3.0)
|
||||
4. THE Stop_Loss_Manager SHALL activate trailing stop when unrealized_gain_pct >= 0.50 × take_profit_distance_pct
|
||||
5. THE Stop_Loss_Manager SHALL compute trailing_stop = max(existing_stop, current_price × (1 - trailing_distance_pct)) where trailing_distance_pct = max(ATR_pct × trailing_ATR_mult, sigma_h × 0.75)
|
||||
|
||||
### Requirement 17: Data Quality v3 (Multiplicative Fail-Closed)
|
||||
|
||||
**User Story:** As the suppression layer, I want data quality computed as a multiplicative fail-closed metric, so that a single catastrophic quality failure suppresses the entire recommendation.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE V3_Engine SHALL compute Q_parse = 1 - extraction_failure_rate
|
||||
2. THE V3_Engine SHALL compute Q_conf = weighted_mean(extraction_conf_i, weight=impact_i)
|
||||
3. THE V3_Engine SHALL compute Q_fresh = exp(-age_newest_hours / 168)
|
||||
4. THE V3_Engine SHALL compute Q_coverage = 1 - exp(-N_valid / 5)
|
||||
5. THE V3_Engine SHALL compute Q_diversity = min(1, log2(1 + N_source_types) / log2(4))
|
||||
6. THE V3_Engine SHALL compute data_quality_score = clamp(Q_parse × sqrt(Q_conf) × Q_fresh × Q_coverage × Q_diversity, 0, 1)
|
||||
7. IF data_quality_score < 0.50 OR N_valid < 2 OR Q_parse < 0.50, THEN THE V3_Engine SHALL force the recommendation to informational mode
|
||||
8. IF company evidence is zero and only macro or competitive evidence exists, THEN THE V3_Engine SHALL force the recommendation to informational mode unless macro_only_enabled is configured
|
||||
|
||||
### Requirement 18: Risk Tier Auto-Adjustment v3
|
||||
|
||||
**User Story:** As the risk tier controller, I want tier adjustments based on risk-adjusted performance metrics, so that the engine self-corrects when performance degrades.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Risk_Engine SHALL track profit_factor_30d (gross_profit / gross_loss over 30 days), max_drawdown_30d (largest peak-to-trough portfolio decline over 30 days as a fraction), calibration_error (mean absolute difference between predicted P_up and realized binary outcome over 30 days), and realized_sharpe_30d (annualized Sharpe ratio of daily returns over 30 days)
|
||||
2. THE Risk_Engine SHALL evaluate tier adjustment conditions once per calendar day after the trading session closes
|
||||
3. THE Risk_Engine SHALL downgrade one tier if any condition is met: profit_factor_30d < 1.0 OR max_drawdown_30d > 0.12 OR calibration_error > 0.20 OR realized_sharpe_30d < 0
|
||||
4. THE Risk_Engine SHALL upgrade one tier only if all conditions are met: profit_factor_30d > 1.35 AND max_drawdown_30d < 0.05 AND calibration_error < 0.12 AND reserve_pool > 0.20 AND N_trades_30d >= 20
|
||||
5. IF a downgrade condition is triggered, THEN THE Risk_Engine SHALL apply the downgrade immediately without waiting for an upgrade evaluation
|
||||
6. THE Risk_Engine SHALL enforce a minimum cooldown of 7 calendar days between consecutive upgrade evaluations to prevent tier oscillation
|
||||
|
||||
### Requirement 19: Feature Flag and Fallback
|
||||
|
||||
**User Story:** As an operator, I want the v3 engine gated behind a runtime feature flag with the heuristic mode as fallback, so that the upgrade can be rolled out safely without downtime.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHILE `v3_engine_enabled` is False, THE V3_Engine SHALL route all aggregation through the existing heuristic pipeline without any v3 computation
|
||||
2. WHILE `v3_engine_enabled` is True, THE V3_Engine SHALL route all aggregation through the v3 calibrated evidence pipeline
|
||||
3. THE V3_Engine SHALL read the `v3_engine_enabled` flag from the risk_configs table at the start of each aggregation cycle without requiring a service restart
|
||||
4. IF the v3 pipeline encounters an unhandled error during aggregation, THEN THE V3_Engine SHALL log the error at ERROR level with full traceback and fall back to heuristic mode for that aggregation cycle, recording the fallback event in output metadata
|
||||
5. THE V3_Engine SHALL store a `pipeline_mode` field value of "v3" or "heuristic" in all output records (TrendSummary, Recommendation) JSONB metadata indicating which pipeline produced the result
|
||||
6. IF the `v3_engine_enabled` flag cannot be read from the database (connection error or missing row), THEN THE V3_Engine SHALL default to heuristic mode and log a warning
|
||||
|
||||
### Requirement 20: Database Compatibility and Output Contract
|
||||
|
||||
**User Story:** As the system architect, I want v3 output stored in existing tables using JSONB metadata, so that no schema migration or downtime is required.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE V3_Engine SHALL store posterior fields (p_up, log_odds, strength, confidence, contradiction, n_eff, data_quality) in the existing TrendSummary JSONB metadata column
|
||||
2. THE V3_Engine SHALL store return model fields (mu_h, sigma_h, ev_long, min_edge) in the Recommendation JSONB metadata column
|
||||
3. THE V3_Engine SHALL expose an explainability payload containing top_positive_clusters, top_negative_clusters, suppression_reasons, and risk_adjustments
|
||||
4. THE V3_Engine SHALL preserve the existing WeightedSignal abstraction as an intermediate representation before LLR conversion
|
||||
5. THE V3_Engine SHALL preserve all existing database table schemas without requiring new migrations for core functionality
|
||||
|
||||
### Requirement 21: Mathematical Correctness Properties
|
||||
|
||||
**User Story:** As a developer, I want property-based tests validating all v3 mathematical invariants, so that correctness is verified across the input space.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. FOR ALL valid EvidenceUnits, THE V3_Engine SHALL produce q_i values in the range [0, 1]
|
||||
2. FOR ALL valid q_i values, THE V3_Engine SHALL produce p_correct values in the range [0.501, 0.85]
|
||||
3. FOR ALL valid signals with direction != 0, THE V3_Engine SHALL produce LLR values with the same sign as direction
|
||||
4. FOR ALL valid cluster configurations, THE V3_Engine SHALL produce n_eff_c values satisfying 0 < n_eff_c <= N (where N is the cluster size)
|
||||
5. FOR ALL valid cluster LLRs, THE Bayesian_Service SHALL produce P_up values in the range (0, 1) exclusive
|
||||
6. FOR ALL valid inputs, THE V3_Engine SHALL produce confidence values in the range [0, 1]
|
||||
7. FOR ALL valid inputs with no opposing evidence, THE Contradiction_Service SHALL produce a contradiction score of 0
|
||||
8. FOR ALL valid inputs, THE Position_Sizer SHALL produce portfolio_pct values in the range [0, max_position_pct]
|
||||
9. FOR ALL valid inputs where f_kelly <= 0, THE Position_Sizer SHALL produce a portfolio_pct of 0
|
||||
10. FOR ALL valid EvidenceUnit sequences, serializing the posterior state to JSON and deserializing SHALL produce an equivalent posterior state (round-trip property)
|
||||
@@ -0,0 +1,451 @@
|
||||
# Implementation Plan: Math Core v3 Engine
|
||||
|
||||
## Overview
|
||||
|
||||
Incremental upgrade of the Stonks Oracle signal processing engine from dual-mode heuristic/probabilistic to the v3 Calibrated Evidence Engine. Implementation follows the v3 math doc section 20 order: EvidenceUnit → reliability → LLR → clustering → posterior → contradiction → confidence → macro/competitive layers → EV gate → Kelly sizing → stop-defined heat → retire heuristic scoring. All v3 code operates behind the `v3_engine_enabled` feature flag with heuristic fallback.
|
||||
|
||||
## Tasks
|
||||
|
||||
- [x] 1. EvidenceUnit and LLR conversion behind feature flag
|
||||
- [x] 1.1 Implement EvidenceUnit dataclass and normalization functions in `services/aggregation/scoring.py`
|
||||
- Add frozen dataclass `EvidenceUnit` with all 16 fields (symbol, layer, event_type, source_id, source_group, timestamp, horizon, direction, sentiment_strength, impact, extraction_conf, source_cred, novelty, event_base_rate, cluster_id)
|
||||
- Implement `normalize_company_signal()`, `normalize_macro_signal()`, `normalize_competitive_signal()`
|
||||
- Validate required fields (symbol, timestamp, source_id) — reject with warning on missing
|
||||
- Substitute 0.5 for missing optional numeric fields
|
||||
- Map direction from sentiment/impact_direction strings (+1/-1/0)
|
||||
- Assign event_base_rate from EVENT_TYPE_BASE_RATES lookup (default 0.10)
|
||||
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8_
|
||||
|
||||
- [x] 1.2 Implement calibrated reliability pipeline (`compute_v3_reliability`) in `services/aggregation/scoring.py`
|
||||
- Add `SourceStats` dataclass (source_id, hits, misses, alpha_0=3, beta_0=3)
|
||||
- Add `ReliabilityComponents` dataclass (q_ext, q_source, q_recency, q_uniqueness, q_i)
|
||||
- Implement q_ext = sigmoid(8.0 × (extraction_conf - 0.55))
|
||||
- Implement q_source via Bayesian shrinkage: E[theta_s] = (alpha_0 + hits) / (alpha_0 + beta_0 + hits + misses), then clamp((E - 0.50) / 0.35, 0, 1)
|
||||
- Implement q_recency = 2^(-age_hours / tau_adaptive) with adaptive half-life formula
|
||||
- Implement q_uniqueness = clamp(0.5 + 0.5 × novelty, 0.5, 1.0) × (1 / sqrt(1 + dup_count))
|
||||
- Implement q_i = clamp(q_ext × q_source × source_cred × q_recency × q_uniqueness, 0, 1)
|
||||
- Apply floor of 0.01 on q_recency only for explainability display
|
||||
- _Requirements: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9_
|
||||
|
||||
- [x] 1.3 Implement LLR conversion (`compute_llr`) in `services/aggregation/scoring.py`
|
||||
- Compute p_correct = clamp(0.50 + 0.35 × q_i × impact × sentiment_strength, 0.501, 0.85)
|
||||
- Compute LLR_i = direction × ln(p_correct / (1 - p_correct))
|
||||
- Return 0.0 for neutral signals (direction == 0)
|
||||
- Ensure LLR sign always matches direction for directional signals
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6_
|
||||
|
||||
- [x] 1.4 Add feature flag routing in `services/aggregation/worker.py`
|
||||
- Read `v3_engine_enabled` from risk_configs table at start of each aggregation cycle
|
||||
- Route to v3 pipeline when True, heuristic when False
|
||||
- Default to heuristic mode if DB read fails (log warning)
|
||||
- Wrap v3 pipeline in try/except — fall back to heuristic on unhandled error (log ERROR with traceback)
|
||||
- Store `pipeline_mode` field ("v3" or "heuristic") in output metadata
|
||||
- _Requirements: 19.1, 19.2, 19.3, 19.4, 19.5, 19.6_
|
||||
|
||||
- [x] 1.5 Write property tests for EvidenceUnit, reliability, and LLR (`tests/test_pbt_v3_reliability.py`)
|
||||
- **Property 1: Reliability q_i is bounded in [0, 1]**
|
||||
- **Property 2: p_correct is bounded in [0.501, 0.85]**
|
||||
- **Property 3: LLR sign matches direction and magnitude is bounded**
|
||||
- **Property 4: Neutral signals produce zero LLR**
|
||||
- **Property 21: EvidenceUnit normalization preserves field ranges**
|
||||
- **Validates: Requirements 1.1–1.8, 2.1–2.9, 3.1–3.6, 21.1–21.3**
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 1.6 Write unit tests for EvidenceUnit normalization and LLR conversion (`tests/test_v3_evidence_unit.py`)
|
||||
- Test company signal → EvidenceUnit with correct field mapping
|
||||
- Test macro signal → EvidenceUnit with correct horizon mapping (short_term→7d, medium_term→30d, long_term→90d)
|
||||
- Test competitive signal → EvidenceUnit with correct direction mapping
|
||||
- Test missing required fields → rejection with warning
|
||||
- Test missing optional fields → default 0.5 substitution
|
||||
- Test known inputs through full q_i pipeline → expected outputs
|
||||
- Test LLR boundary cases: p_correct at clamp boundaries
|
||||
- _Requirements: 1.1–1.8, 2.1–2.9, 3.1–3.6_
|
||||
|
||||
- [x] 2. Evidence clustering and n_eff
|
||||
|
||||
- [x] 2.1 Implement correlation-aware clustering in `services/aggregation/worker.py`
|
||||
- Add `EvidenceCluster` dataclass (cluster_id, units, llrs, n_eff, cluster_llr)
|
||||
- Implement `cluster_evidence()` — group EvidenceUnits by (symbol, horizon, event_type, source_group, time_bucket)
|
||||
- Compute cluster_id as hash of grouping key
|
||||
- Define time_bucket resolution per horizon (intraday=1h, 1d=4h, 7d=24h, 30d=72h, 90d=168h)
|
||||
- _Requirements: 4.1_
|
||||
|
||||
- [x] 2.2 Implement n_eff computation in `services/aggregation/worker.py`
|
||||
- Implement `compute_n_eff(llrs, correlations)` using formula: (sum w_i)² / (sum w_i² + 2 × sum_{i<j} rho_ij × w_i × w_j)
|
||||
- Use default pairwise correlations: same wire=0.80, same event diff publisher=0.50, same theme diff event=0.25, independent=0.00
|
||||
- Guard against division by zero (denominator → return n_eff=1.0)
|
||||
- _Requirements: 4.2, 4.3_
|
||||
|
||||
- [x] 2.3 Implement cluster LLR computation in `services/aggregation/worker.py`
|
||||
- Implement `compute_cluster_llr(llrs, n_eff)` = clamp(weighted_mean(LLR_i, |LLR_i|) × sqrt(n_eff), -2.5, 2.5)
|
||||
- Handle single-signal clusters (LLR_c = LLR_i clamped)
|
||||
- Handle all-zero LLR clusters (cluster_llr = 0.0)
|
||||
- _Requirements: 4.4, 4.5_
|
||||
|
||||
- [x] 2.4 Write property tests for clustering (`tests/test_pbt_v3_clustering.py`)
|
||||
- **Property 5: Effective evidence count n_eff is bounded by cluster size**
|
||||
- **Property 6: Cluster LLR is clamped to [-2.5, 2.5]**
|
||||
- **Validates: Requirements 4.2, 4.3, 4.4, 4.5, 21.4**
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 2.5 Write unit tests for clustering (`tests/test_v3_clustering.py`)
|
||||
- Test 3 identical articles from same source → n_eff < 3
|
||||
- Test 3 independent articles → n_eff ≈ 3
|
||||
- Test single signal cluster → n_eff = 1.0
|
||||
- Test cluster LLR clamp at ±2.5
|
||||
- Test grouping by correct key dimensions
|
||||
- _Requirements: 4.1–4.5_
|
||||
|
||||
- [x] 3. Checkpoint - Verify foundation layer
|
||||
- Ensure all tests pass for EvidenceUnit, reliability, LLR, and clustering.
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 4. Replace trend assembly with posterior P_up
|
||||
|
||||
- [x] 4.1 Implement regime detection v3 in `services/aggregation/regime.py`
|
||||
- Add `V3RegimeClassification` dataclass (regime, trend_z, vol_ratio, evidence_multiplier, confidence_multiplier, phi_decay, atr_multiplier)
|
||||
- Implement `classify_regime_v3(closing_prices, daily_returns, atr_20)` using ATR-normalized trend_z = (EMA_20 - EMA_100) / ATR_20
|
||||
- Compute vol_ratio = sigma_20 / sigma_100
|
||||
- Classification rules in priority: panic (vol_ratio > 1.5 OR |trend_z| > 2.5), trend_following (|trend_z| >= 0.75 AND vol_ratio < 1.3), mean_reversion (|trend_z| < 0.50 AND vol_ratio < 1.0), uncertainty (default)
|
||||
- Assign regime parameters: gamma, confidence_mult, phi, ATR_mult, min_edge
|
||||
- Default to uncertainty when data insufficient
|
||||
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5, 6.6, 6.7, 6.8_
|
||||
|
||||
- [x] 4.2 Implement posterior assembly via log-odds in `services/aggregation/bayesian.py`
|
||||
- Add `V3Posterior` dataclass (p_up, p_down, log_odds, strength, direction, n_eff_total, regime)
|
||||
- Implement `compute_v3_posterior(clusters, regime, p_prior=0.50)`
|
||||
- Compute logit(P_up) = logit(P_prior) + sum(gamma_regime × LLR_c)
|
||||
- Compute P_up = sigmoid(log_odds), clamp to [1e-10, 1 - 1e-10]
|
||||
- Compute strength = abs(2 × P_up - 1)
|
||||
- Classify direction using regime-specific thresholds (panic: 0.68/0.32, trend_following: 0.60/0.40, mean_reversion: 0.63/0.37, uncertainty: 0.65/0.35)
|
||||
- Load calibrated prior from risk_configs if available (clamp to [0.40, 0.60]), fall back to 0.50 on error
|
||||
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7_
|
||||
|
||||
- [x] 4.3 Write property tests for posterior and regime (`tests/test_pbt_v3_posterior.py`)
|
||||
- **Property 7: Posterior P_up is in open interval (0, 1)**
|
||||
- **Property 20: Regime classification is exhaustive and deterministic**
|
||||
- **Validates: Requirements 5.3, 6.2–6.5, 21.5**
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 4.4 Write unit tests for posterior assembly (`tests/test_v3_posterior.py`)
|
||||
- Test empty clusters → P_up = 0.50 (neutral prior)
|
||||
- Test all bullish clusters → P_up > 0.50
|
||||
- Test regime direction thresholds at boundary values
|
||||
- Test prior clamp [0.40, 0.60]
|
||||
- Test regime classification with known inputs
|
||||
- _Requirements: 5.1–5.7, 6.1–6.8_
|
||||
|
||||
- [x] 5. Replace contradiction with LLR entropy
|
||||
|
||||
- [x] 5.1 Implement LLR entropy contradiction in `services/aggregation/contradiction.py`
|
||||
- Add `compute_v3_contradiction(clusters: list[EvidenceCluster]) -> float`
|
||||
- Compute E_pos = sum(max(LLR_c, 0)), E_neg = sum(max(-LLR_c, 0)), E_total = E_pos + E_neg
|
||||
- When E_total == 0 → return 0.0
|
||||
- When only one direction exists (E_pos == 0 or E_neg == 0) → return 0.0
|
||||
- Compute f_pos = E_pos / E_total, f_neg = E_neg / E_total
|
||||
- Compute H_conflict = -f_pos × log2(f_pos) - f_neg × log2(f_neg), treating 0×log2(0) = 0
|
||||
- Compute volume_factor = 1 - exp(-E_total / 3.0)
|
||||
- Return H_conflict × volume_factor, bounded in [0.0, 1.0]
|
||||
- _Requirements: 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7_
|
||||
|
||||
- [x] 5.2 Write property tests for contradiction (`tests/test_pbt_v3_posterior.py`)
|
||||
- **Property 8: Contradiction is zero when evidence is unidirectional**
|
||||
- **Property 9: Contradiction score is bounded in [0, 1]**
|
||||
- **Validates: Requirements 7.6, 7.7, 21.7**
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 5.3 Write unit tests for LLR entropy contradiction (`tests/test_v3_contradiction.py`)
|
||||
- Test all bullish clusters → contradiction = 0.0
|
||||
- Test equal split of evidence → high contradiction near 1.0
|
||||
- Test E_total = 0 → contradiction = 0.0
|
||||
- Test volume_factor growth: small evidence mass → suppressed score
|
||||
- _Requirements: 7.1–7.7_
|
||||
|
||||
- [x] 6. Replace confidence formula
|
||||
|
||||
- [x] 6.1 Implement multiplicative confidence v3 in `services/aggregation/worker.py`
|
||||
- Add `compute_v3_confidence(n_eff_total, q_values, llrs, strength, regime_confidence_mult, contradiction, data_quality) -> float`
|
||||
- Compute C_evidence = 1 - exp(-n_eff_total / 5.0)
|
||||
- Compute C_quality = weighted_mean(q_i, weight=|LLR_i|)
|
||||
- Compute confidence = clamp(C_evidence × sqrt(C_quality) × sqrt(max(strength, 0.05)) × regime_confidence_mult × (1 - contradiction) × data_quality, 0, 1)
|
||||
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5_
|
||||
|
||||
- [x] 6.2 Implement data quality v3 in `services/aggregation/worker.py`
|
||||
- Add `compute_v3_data_quality(units, extraction_failure_rate, age_newest_hours, n_source_types) -> float`
|
||||
- Q_parse = 1 - extraction_failure_rate
|
||||
- Q_conf = weighted_mean(extraction_conf_i, weight=impact_i)
|
||||
- Q_fresh = exp(-age_newest_hours / 168)
|
||||
- Q_coverage = 1 - exp(-N_valid / 5)
|
||||
- Q_diversity = min(1, log2(1 + N_source_types) / log2(4))
|
||||
- data_quality_score = clamp(Q_parse × sqrt(Q_conf) × Q_fresh × Q_coverage × Q_diversity, 0, 1)
|
||||
- Force informational mode when data_quality < 0.50 OR N_valid < 2 OR Q_parse < 0.50
|
||||
- Force informational when only macro/competitive evidence unless macro_only_enabled
|
||||
- _Requirements: 17.1, 17.2, 17.3, 17.4, 17.5, 17.6, 17.7, 17.8_
|
||||
|
||||
- [x] 6.3 Write property tests for confidence and data quality (`tests/test_pbt_v3_posterior.py`)
|
||||
- **Property 10: Multiplicative confidence is bounded in [0, 1] and suppressed by weak dimensions**
|
||||
- **Property 17: Data quality score is bounded in [0, 1]**
|
||||
- **Validates: Requirements 8.3, 8.5, 17.6, 21.6**
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 6.4 Write unit tests for confidence and data quality (`tests/test_v3_confidence.py`)
|
||||
- Test zero data quality → near-zero confidence
|
||||
- Test full contradiction (1.0) → zero confidence
|
||||
- Test low n_eff → suppressed C_evidence
|
||||
- Test data quality boundary cases (Q_parse < 0.50 → informational)
|
||||
- _Requirements: 8.1–8.5, 17.1–17.8_
|
||||
|
||||
- [x] 7. Checkpoint - Verify core pipeline
|
||||
- Ensure all tests pass for posterior, contradiction, confidence, and data quality.
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 8. Convert macro and competitive layers to emit LLR
|
||||
|
||||
- [x] 8.1 Implement noisy-OR macro exposure and LLR emission in `services/aggregation/interpolation.py`
|
||||
- Add `compute_normalized_macro_exposure(overlaps: dict[str, float]) -> float`
|
||||
- E_raw = 1 - product(1 - w_k × O_k) with weights: w_geo=0.35, w_supply=0.25, w_commodity=0.25, w_sector=0.15
|
||||
- E_max = 1 - product(1 - w_k)
|
||||
- E_macro = E_raw / E_max (normalized to [0, 1])
|
||||
- Apply resilience dampener per tier: global_leader=0.70, multinational=0.85, regional=1.00, domestic=1.20
|
||||
- Add `compute_macro_llr(macro_impact, event_confidence, q_recency, macro_direction) -> float`
|
||||
- p_macro = clamp(0.50 + 0.30 × macro_impact × event_confidence × q_recency, 0.501, 0.80)
|
||||
- LLR_macro = macro_direction × ln(p_macro / (1 - p_macro))
|
||||
- Feed macro LLR into shared posterior without separate post-hoc modifier
|
||||
- _Requirements: 9.1, 9.2, 9.3, 9.4, 9.5_
|
||||
|
||||
- [x] 8.2 Implement correlation-shrunk competitive propagation in `services/aggregation/signal_propagation.py`
|
||||
- Add `compute_shrunk_correlation(rho_rolling, n_observations, same_sector) -> float`
|
||||
- rho_prior = 0.30 (same_sector) or 0.10 (cross_sector)
|
||||
- rho_shrunk = (n/(n+30)) × rho_rolling + (30/(n+30)) × rho_prior
|
||||
- rho_effective = max(rho_shrunk, 0)
|
||||
- Add `compute_competitive_llr(llr_source, rho_effective, d_network, pattern_confidence) -> float`
|
||||
- attenuation = rho_effective × exp(-0.85 × d_network), max_distance = 3
|
||||
- LLR_competitive = clamp(llr_source × attenuation × pattern_confidence, -1.25, 1.25)
|
||||
- _Requirements: 10.1, 10.2, 10.3, 10.4, 10.5_
|
||||
|
||||
- [x] 8.3 Write property tests for macro and competitive layers (`tests/test_pbt_v3_layers.py`)
|
||||
- **Property 13: Noisy-OR normalized exposure is bounded in [0, 1]**
|
||||
- **Property 14: Competitive LLR is clamped to [-1.25, 1.25]**
|
||||
- **Property 15: Graph attenuation is zero beyond max distance**
|
||||
- **Validates: Requirements 9.1, 9.2, 10.3, 10.4, 10.5**
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 8.4 Write unit tests for macro and competitive layers (`tests/test_v3_layers.py`)
|
||||
- Test noisy-OR: all O_k = 1.0 → E_macro = 1.0; all O_k = 0 → E_macro = 0
|
||||
- Test resilience dampener per tier
|
||||
- Test macro LLR at boundary values
|
||||
- Test shrunk correlation convergence (n → ∞ approaches rho_rolling)
|
||||
- Test competitive LLR clamp at ±1.25
|
||||
- Test distance > 3 → zero attenuation
|
||||
- _Requirements: 9.1–9.5, 10.1–10.5_
|
||||
|
||||
- [x] 9. Replace EV gate with expected-return distribution
|
||||
|
||||
- [x] 9.1 Implement posterior state projection in `services/aggregation/projection.py`
|
||||
- Add `V3ProjectionState` dataclass (a_t, p_up_projected, projected_strength, diverges, phi_regime)
|
||||
- Implement `compute_v3_projection(a_prev, cluster_llrs, regime, p_prior, projection_horizon, known_catalyst_llr=0.0)`
|
||||
- Evidence state: A_t = phi_regime × A_{t-1} + sum(LLR_c), init A_0 = 0.0
|
||||
- Regime decay: panic=0.35, trend_following=0.80, mean_reversion=0.55, uncertainty=0.50
|
||||
- Projected alpha: A_projected = phi^h × A_t + known_catalyst_LLR
|
||||
- P_up_projected = sigmoid(logit(P_prior) + A_projected)
|
||||
- Projected strength = abs(2 × P_up_projected - 1)
|
||||
- Flag divergence when sign(P_up_projected - 0.5) ≠ sign(P_up_t - 0.5)
|
||||
- _Requirements: 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7_
|
||||
|
||||
- [x] 9.2 Implement return distribution and EV gate in `services/recommendation/eligibility.py`
|
||||
- Add `ReturnDistribution` dataclass (sigma_h, mu_h, ev_long, min_edge, eligible)
|
||||
- Add `compute_return_distribution(a_projected, confidence, realized_vol_20d, horizon_days, costs, regime)`
|
||||
- sigma_h = realized_vol_20d × sqrt(horizon_days / 252); default vol = 0.25 if unavailable
|
||||
- mu_h = tanh(A_projected / 3.0) × confidence × sigma_h
|
||||
- CVaR_5 = sigma_h × 1.645 × 1.4
|
||||
- EV_long = mu_h - costs - 0.10 × CVaR_5
|
||||
- Regime min_edge: panic=0.0100, trend_following=0.0035, mean_reversion=0.0050, uncertainty=0.0075
|
||||
- Eligibility: EV_long > min_edge AND EV_long > max(0.0025, 0.25 × costs)
|
||||
- Also require: confidence >= regime_confidence_min, contradiction <= regime_contradiction_max, n_eff_total >= 2.0, data_quality >= 0.50
|
||||
- _Requirements: 12.1, 12.2, 12.3, 12.4, 12.5, 12.6, 12.7_
|
||||
|
||||
- [x] 9.3 Implement regime-aware eligibility and mode escalation in `services/recommendation/eligibility.py`
|
||||
- Add regime-specific eligibility thresholds: panic (conf≥0.70, contra≤0.25, str≥0.36), trend_following (conf≥0.55, contra≤0.40, str≥0.20), mean_reversion (conf≥0.60, contra≤0.35, str≥0.26), uncertainty (conf≥0.65, contra≤0.30, str≥0.30)
|
||||
- Action mapping: BUY when P_up >= bullish_threshold and EV > min_edge; SELL when existing position and EV_exit > EV_hold; HOLD when existing; WATCH otherwise
|
||||
- live_eligible: BUY/SELL + conf >= 0.75 + contra <= 0.20 + n_eff >= 5 + EV > 2×min_edge + risk_passed
|
||||
- paper_eligible: BUY/SELL + conf >= 0.60 + EV > min_edge + risk_passed
|
||||
- Otherwise: informational
|
||||
- _Requirements: 13.1, 13.2, 13.3, 13.4, 13.5_
|
||||
|
||||
- [x] 9.4 Write property tests for projection (`tests/test_pbt_v3_projection.py`)
|
||||
- **Property 16: Projection evidence state decays toward zero**
|
||||
- **Validates: Requirements 11.1, 11.3**
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 9.5 Write unit tests for EV gate and eligibility (`tests/test_v3_eligibility.py`)
|
||||
- Test EV_long positive → eligible
|
||||
- Test EV_long negative → ineligible
|
||||
- Test regime-specific min_edge thresholds
|
||||
- Test mode escalation: live vs paper vs informational
|
||||
- Test projection decay convergence
|
||||
- Test divergence flag behavior
|
||||
- _Requirements: 11.1–11.7, 12.1–12.7, 13.1–13.5_
|
||||
|
||||
- [x] 10. Checkpoint - Verify decision layer
|
||||
- Ensure all tests pass for projection, EV gate, eligibility, and layer integrations.
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 11. Replace sizing with fractional Kelly under existing risk caps
|
||||
|
||||
- [x] 11.1 Implement fractional Kelly position sizing in `services/trading/position_sizer.py`
|
||||
- Add `compute_kelly_sizing(p_win, b, confidence, data_quality, contradiction, max_position_pct, available_caps) -> float`
|
||||
- Compute reward ratio b = clamp(1.2 + 2.0 × confidence + 1.0 × strength - contradiction, 1.2, 3.0)
|
||||
- Compute f_kelly = (p_win × b - (1 - p_win)) / b
|
||||
- portfolio_pct = clamp(max(0, f_kelly) × 0.25 × confidence × data_quality × (1 - contradiction), 0, max_position_pct)
|
||||
- Apply min of: max_position_pct, sector_capacity, correlation_capacity (0 if avg corr > 0.80), heat_capacity
|
||||
- If portfolio_pct < 0.005 → downgrade to WATCH (reason: position_below_minimum)
|
||||
- If f_kelly <= 0 → portfolio_pct = 0, downgrade to WATCH (reason: negative_edge)
|
||||
- _Requirements: 14.1, 14.2, 14.3, 14.4, 14.5, 14.6, 14.7_
|
||||
|
||||
- [x] 11.2 Implement regime-aware stop loss and take profit in `services/trading/stop_loss_manager.py`
|
||||
- Add v3 stop computation: stop_distance_pct = max(ATR_pct × regime_ATR_mult, sigma_h × 1.25, 0.005)
|
||||
- stop_loss = entry_price × (1 - stop_distance_pct)
|
||||
- take_profit = entry_price × (1 + b × stop_distance_pct) where b = reward ratio
|
||||
- Activate trailing stop when unrealized_gain >= 0.50 × TP distance
|
||||
- trailing_stop = max(existing_stop, current_price × (1 - trailing_distance_pct))
|
||||
- trailing_distance_pct = max(ATR_pct × trailing_ATR_mult, sigma_h × 0.75)
|
||||
- Trailing stop must be monotonically non-decreasing
|
||||
- _Requirements: 16.1, 16.2, 16.3, 16.4, 16.5_
|
||||
|
||||
- [x] 11.3 Write property tests for Kelly sizing and stops (`tests/test_pbt_v3_decision.py`)
|
||||
- **Property 11: Fractional Kelly sizing is bounded and respects negative edge**
|
||||
- **Property 18: Stop loss is below entry price and take profit is above**
|
||||
- **Property 19: Trailing stop never decreases**
|
||||
- **Validates: Requirements 14.4, 14.7, 16.2, 16.3, 16.5, 21.8, 21.9**
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 11.4 Write unit tests for Kelly sizing and stops (`tests/test_v3_sizing.py`)
|
||||
- Test p_win=0.3, b=2 → f_kelly < 0 → size = 0
|
||||
- Test p_win=0.7, b=2 → positive size within caps
|
||||
- Test cap enforcement (sector, correlation, heat)
|
||||
- Test position_below_minimum downgrade
|
||||
- Test stop/TP computation with known inputs
|
||||
- Test trailing stop monotonicity over a price sequence
|
||||
- _Requirements: 14.1–14.7, 16.1–16.5_
|
||||
|
||||
- [x] 12. Replace portfolio heat with stop-defined risk dollars
|
||||
|
||||
- [x] 12.1 Implement stop-defined portfolio heat in `services/risk/engine.py`
|
||||
- Add `compute_portfolio_heat(positions, stop_distances) -> float`
|
||||
- risk_dollars = position_value × stop_distance_pct for each position
|
||||
- portfolio_heat = sum(risk_dollars)
|
||||
- Add `check_heat_capacity(current_heat, new_risk_dollars, max_heat_pct, portfolio_value) -> bool`
|
||||
- Reject new entry when current_heat + new_risk_dollars > max_heat_pct × portfolio_value
|
||||
- Integrate available_heat_capacity into Kelly sizing pipeline
|
||||
- _Requirements: 15.1, 15.2, 15.3, 15.4, 15.5_
|
||||
|
||||
- [x] 12.2 Implement risk tier auto-adjustment v3 in `services/risk/engine.py`
|
||||
- Add `TierMetrics` dataclass (profit_factor_30d, max_drawdown_30d, calibration_error, realized_sharpe_30d, n_trades_30d, reserve_pool_pct)
|
||||
- Add `evaluate_tier_adjustment(metrics) -> str` returning 'upgrade'|'downgrade'|'hold'
|
||||
- Downgrade if ANY: profit_factor < 1.0 OR drawdown > 0.12 OR calibration_error > 0.20 OR sharpe < 0
|
||||
- Upgrade only if ALL: profit_factor > 1.35 AND drawdown < 0.05 AND calibration_error < 0.12 AND reserve > 0.20 AND N_trades >= 20
|
||||
- Apply downgrade immediately; enforce 7-day upgrade cooldown
|
||||
- Evaluate once per calendar day after session close
|
||||
- _Requirements: 18.1, 18.2, 18.3, 18.4, 18.5, 18.6_
|
||||
|
||||
- [x] 12.3 Write property tests for heat and tier adjustment (`tests/test_pbt_v3_decision.py`)
|
||||
- **Property 22: Portfolio heat rejection is correct**
|
||||
- **Property 23: Tier auto-adjustment obeys downgrade-any, upgrade-all logic**
|
||||
- **Validates: Requirements 15.3, 15.5, 18.3, 18.4**
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 12.4 Write unit tests for heat and tier (`tests/test_v3_risk.py`)
|
||||
- Test heat computation: 3 positions with known stops → expected heat
|
||||
- Test heat rejection: heat at limit → new entry blocked
|
||||
- Test tier downgrade: single bad metric triggers downgrade
|
||||
- Test tier upgrade: all metrics good → upgrade
|
||||
- Test tier upgrade: one metric bad → hold (not upgrade)
|
||||
- Test 7-day cooldown enforcement
|
||||
- _Requirements: 15.1–15.5, 18.1–18.6_
|
||||
|
||||
- [x] 13. Checkpoint - Verify sizing and risk layer
|
||||
- Ensure all tests pass for Kelly sizing, stops, heat, and tier adjustment.
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 14. Retire heuristic scoring to explainability-only mode
|
||||
|
||||
- [x] 14.1 Wire v3 pipeline end-to-end in `services/aggregation/worker.py`
|
||||
- Orchestrate full pipeline: EvidenceUnit → q_i → LLR → cluster → posterior → contradiction → confidence → data_quality
|
||||
- Store v3 posterior in TrendSummary JSONB metadata (p_up, log_odds, strength, confidence, contradiction, n_eff, data_quality, regime)
|
||||
- Store return model in Recommendation JSONB metadata (mu_h, sigma_h, ev_long, min_edge)
|
||||
- Store explainability payload (top_positive_clusters, top_negative_clusters, suppression_reasons, risk_adjustments)
|
||||
- Preserve WeightedSignal as intermediate representation before LLR conversion
|
||||
- _Requirements: 20.1, 20.2, 20.3, 20.4, 20.5_
|
||||
|
||||
- [x] 14.2 Retain heuristic pipeline as fallback with explainability overlay
|
||||
- Keep existing heuristic scoring path fully functional (no removal)
|
||||
- Mark heuristic outputs with `pipeline_mode: "heuristic"` in metadata
|
||||
- Ensure heuristic mode still produces valid TrendSummary and Recommendation objects
|
||||
- Test feature flag toggle: v3 → heuristic → v3 round-trip
|
||||
- _Requirements: 19.1, 19.2, 19.5, 20.4_
|
||||
|
||||
- [x] 14.3 Write property test for JSON round-trip (`tests/test_pbt_v3_posterior.py`)
|
||||
- **Property 12: Posterior state JSON round-trip**
|
||||
- **Validates: Requirements 20.1, 21.10**
|
||||
- Serialize V3Posterior to JSON and deserialize, verify equivalence within 1e-10
|
||||
- Use Hypothesis with `@settings(max_examples=100)`
|
||||
|
||||
- [x] 14.4 Write integration tests for full pipeline (`tests/test_v3_integration.py`)
|
||||
- Test full path: raw signals → EvidenceUnit → q_i → LLR → cluster → posterior → recommendation
|
||||
- Test feature flag false → heuristic path, flag true → v3 path
|
||||
- Test v3 exception → heuristic fallback + error logged
|
||||
- Test output JSONB contains expected v3 fields
|
||||
- _Requirements: 19.1–19.6, 20.1–20.5_
|
||||
|
||||
- [x] 15. Final checkpoint - All tests green
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
- Run full test suite: `.venv/bin/python -m pytest tests/test_pbt_v3_*.py tests/test_v3_*.py -x --tb=short -q`
|
||||
- Verify no regressions in existing heuristic pipeline tests
|
||||
|
||||
## Notes
|
||||
|
||||
- Tasks marked with `*` are optional and can be skipped for faster MVP
|
||||
- Each task references specific requirements for traceability
|
||||
- Checkpoints ensure incremental validation after each logical phase
|
||||
- Property tests validate the 23 correctness properties defined in the design
|
||||
- Unit tests validate specific examples, edge cases, and error handling
|
||||
- The implementation preserves the existing heuristic pipeline as a fully functional fallback
|
||||
- All v3 code is gated behind `v3_engine_enabled` — no changes to production behavior until flag is flipped
|
||||
- Run tests with: `.venv/bin/python -m pytest tests/ -x --tb=short -q`
|
||||
- Property tests use Hypothesis: `@settings(max_examples=100)`
|
||||
|
||||
## Task Dependency Graph
|
||||
|
||||
```json
|
||||
{
|
||||
"waves": [
|
||||
{ "id": 0, "tasks": ["1.1"] },
|
||||
{ "id": 1, "tasks": ["1.2", "1.4"] },
|
||||
{ "id": 2, "tasks": ["1.3"] },
|
||||
{ "id": 3, "tasks": ["1.5", "1.6"] },
|
||||
{ "id": 4, "tasks": ["2.1"] },
|
||||
{ "id": 5, "tasks": ["2.2"] },
|
||||
{ "id": 6, "tasks": ["2.3"] },
|
||||
{ "id": 7, "tasks": ["2.4", "2.5"] },
|
||||
{ "id": 8, "tasks": ["4.1"] },
|
||||
{ "id": 9, "tasks": ["4.2"] },
|
||||
{ "id": 10, "tasks": ["4.3", "4.4"] },
|
||||
{ "id": 11, "tasks": ["5.1"] },
|
||||
{ "id": 12, "tasks": ["5.2", "5.3"] },
|
||||
{ "id": 13, "tasks": ["6.1", "6.2"] },
|
||||
{ "id": 14, "tasks": ["6.3", "6.4"] },
|
||||
{ "id": 15, "tasks": ["8.1", "8.2"] },
|
||||
{ "id": 16, "tasks": ["8.3", "8.4"] },
|
||||
{ "id": 17, "tasks": ["9.1"] },
|
||||
{ "id": 18, "tasks": ["9.2", "9.3"] },
|
||||
{ "id": 19, "tasks": ["9.4", "9.5"] },
|
||||
{ "id": 20, "tasks": ["11.1", "11.2"] },
|
||||
{ "id": 21, "tasks": ["11.3", "11.4"] },
|
||||
{ "id": 22, "tasks": ["12.1", "12.2"] },
|
||||
{ "id": 23, "tasks": ["12.3", "12.4"] },
|
||||
{ "id": 24, "tasks": ["14.1"] },
|
||||
{ "id": 25, "tasks": ["14.2"] },
|
||||
{ "id": 26, "tasks": ["14.3", "14.4"] }
|
||||
]
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1 @@
|
||||
{"specId": "b595d834-7e72-4fab-87a9-65c92115a069", "workflowType": "requirements-first", "specType": "feature"}
|
||||
@@ -0,0 +1,975 @@
|
||||
# Design Document — Model Validation, Calibration, and Signal Quality
|
||||
|
||||
## Overview
|
||||
|
||||
This design adds a closed-loop model validation layer to Stonks Oracle. The system currently generates trend summaries and trading recommendations with confidence scores, but has no mechanism to evaluate whether those predictions are accurate, whether confidence scores are well-calibrated, which sources contribute to correct predictions, or whether the system outperforms simple benchmarks.
|
||||
|
||||
The validation layer introduces six new service modules under `services/validation/`, a quality gate in `services/trading/`, seven new API endpoints under `/api/validation/`, a database migration (035) with four new tables and two SQL views, and an upgraded OpsModel dashboard page. The architecture follows the existing patterns: pure computation modules with asyncpg for persistence, FastAPI endpoints in `services/api/app.py`, and React/TanStack Query hooks on the frontend.
|
||||
|
||||
### Design Rationale
|
||||
|
||||
A prediction engine without outcome tracking is flying blind. The validation layer closes the feedback loop by:
|
||||
|
||||
1. **Capturing immutable snapshots** at prediction time — preventing hindsight bias in evaluation
|
||||
2. **Evaluating outcomes** across multiple horizons (1h, 6h, 1d, 7d, 30d) — matching the system's multi-window trend architecture
|
||||
3. **Computing calibration metrics** (ECE, Brier score) — measuring whether confidence scores mean what they claim
|
||||
4. **Tracking information coefficients** (IC, Rank IC) — measuring linear and ordinal predictive power
|
||||
5. **Attributing performance** to sources, catalysts, and signal layers — identifying the most valuable information channels
|
||||
6. **Recalibrating confidence** via Bayesian shrinkage — learning from the system's own track record
|
||||
7. **Gating live trading** on minimum quality thresholds — preventing real capital risk on a poorly performing model
|
||||
|
||||
The design reuses existing infrastructure (asyncpg, FastAPI, TanStack Query, Recharts) and integrates with the existing `source_accuracy` table from the signal-math-upgrade spec.
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
### High-Level Data Flow
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph "Prediction Capture (Real-time)"
|
||||
A[Recommendation Engine] -->|generates| B[Prediction_Snapshot_Writer]
|
||||
B --> C[prediction_snapshots table]
|
||||
B --> D[signal_evidence_links table]
|
||||
B -->|computes| E[canonical_evidence_key<br/>duplicate detection<br/>contribution scores]
|
||||
end
|
||||
|
||||
subgraph "Outcome Evaluation (Periodic)"
|
||||
F[Outcome_Evaluator<br/>scheduled job] -->|reads matured snapshots| C
|
||||
F -->|fetches future prices| G[market_snapshots table]
|
||||
F -->|computes returns| H[prediction_outcomes table]
|
||||
F -->|evaluates 5 horizons| H
|
||||
end
|
||||
|
||||
subgraph "Metrics Computation (Periodic)"
|
||||
I[Metrics_Engine] -->|reads| H
|
||||
I -->|reads| C
|
||||
I -->|reads| D
|
||||
I -->|computes| J[model_metric_snapshots table]
|
||||
I -->|computes| K[Calibration: ECE, Brier]
|
||||
I -->|computes| L[IC, Rank IC by horizon]
|
||||
I -->|computes| M[Benchmark: excess returns]
|
||||
end
|
||||
|
||||
subgraph "Attribution (Periodic)"
|
||||
N[Attribution_Engine] -->|joins| D
|
||||
N -->|joins| H
|
||||
N -->|computes| O[Per-source metrics]
|
||||
N -->|computes| P[Per-catalyst metrics]
|
||||
N -->|computes| Q[Per-layer metrics]
|
||||
end
|
||||
|
||||
subgraph "Calibration (Periodic)"
|
||||
R[Calibration_Engine] -->|reads| H
|
||||
R -->|reads| D
|
||||
R -->|computes Bayesian shrinkage| S[source_accuracy table<br/>reliability scores]
|
||||
end
|
||||
|
||||
subgraph "Safety Gate (Per-cycle)"
|
||||
T[Quality_Gate] -->|reads latest| J
|
||||
T -->|evaluates thresholds| U{Pass?}
|
||||
U -->|yes| V[Live trading allowed]
|
||||
U -->|no| W[Force paper mode]
|
||||
T -->|stores result| X[risk_configs table<br/>model_quality_gate key]
|
||||
end
|
||||
|
||||
subgraph "Dashboard (Frontend)"
|
||||
Y[Dashboard_API<br/>7 endpoints] -->|reads| J
|
||||
Y -->|reads| C
|
||||
Y -->|reads| H
|
||||
Y -->|reads| D
|
||||
Z[OpsModel.tsx<br/>upgraded page] -->|fetches| Y
|
||||
end
|
||||
|
||||
subgraph "Backtest Integration"
|
||||
AA[BacktestReplay] -->|validation mode| B
|
||||
AA -->|validation mode| F
|
||||
AA -->|triggers| I
|
||||
end
|
||||
```
|
||||
|
||||
### Scheduling Strategy
|
||||
|
||||
The validation components run on different cadences:
|
||||
|
||||
| Component | Trigger | Cadence |
|
||||
|-----------|---------|---------|
|
||||
| Prediction_Snapshot_Writer | Synchronous — called by recommendation engine | Every recommendation |
|
||||
| Outcome_Evaluator | Scheduled job | Every 1 hour |
|
||||
| Metrics_Engine | After Outcome_Evaluator completes | Every 1 hour |
|
||||
| Attribution_Engine | Called by Metrics_Engine | Every 1 hour |
|
||||
| Calibration_Engine | After Metrics_Engine completes | Every 6 hours |
|
||||
| Quality_Gate | Start of each aggregation cycle | Every aggregation cycle |
|
||||
|
||||
### Sector ETF Mapping
|
||||
|
||||
The system needs a mapping from company sectors to sector ETFs for benchmark comparison. This is stored as a configuration constant:
|
||||
|
||||
```python
|
||||
SECTOR_ETF_MAP: dict[str, str] = {
|
||||
"Technology": "XLK",
|
||||
"Consumer Cyclical": "XLY",
|
||||
"Financial Services": "XLF",
|
||||
"Healthcare": "XLV",
|
||||
"Energy": "XLE",
|
||||
"Communication Services": "XLC",
|
||||
"Industrials": "XLI",
|
||||
"Consumer Defensive": "XLP",
|
||||
"Real Estate": "XLRE",
|
||||
"Utilities": "XLU",
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Components and Interfaces
|
||||
|
||||
### New Modules
|
||||
|
||||
| Module | File | Responsibility |
|
||||
|--------|------|----------------|
|
||||
| Prediction Snapshot Writer | `services/validation/prediction_snapshot.py` | Captures immutable prediction state at generation time |
|
||||
| Outcome Evaluator | `services/validation/outcome_evaluator.py` | Matches predictions with realized market outcomes |
|
||||
| Metrics Engine | `services/validation/metrics.py` | Computes calibration, IC, Brier, benchmark metrics |
|
||||
| Attribution Engine | `services/validation/attribution.py` | Per-source, per-catalyst, per-layer performance |
|
||||
| Calibration Engine | `services/validation/calibration.py` | Bayesian shrinkage source reliability, weight adjustment |
|
||||
| Quality Gate | `services/trading/model_quality_gate.py` | Safety gate for live trading eligibility |
|
||||
|
||||
### Modified Modules
|
||||
|
||||
| Module | File | Changes |
|
||||
|--------|------|---------|
|
||||
| Query API | `services/api/app.py` | 7 new `/api/validation/*` endpoints |
|
||||
| Aggregation Worker | `services/aggregation/worker.py` | Call Quality_Gate at cycle start |
|
||||
| Recommendation Engine | `services/recommendation/eligibility.py` | Call Prediction_Snapshot_Writer after recommendation |
|
||||
| Backtest Replay | `services/trading/backtest_replay.py` | Validation mode support |
|
||||
| Frontend Hooks | `frontend/src/api/hooks.ts` | 7 new validation hooks |
|
||||
| OpsModel Page | `frontend/src/pages/OpsModel.tsx` | Full dashboard upgrade |
|
||||
| AppLayout | `frontend/src/components/AppLayout.tsx` | Nav item update (if needed) |
|
||||
|
||||
### Component Interface Details
|
||||
|
||||
#### 1. Prediction Snapshot Writer (`services/validation/prediction_snapshot.py`)
|
||||
|
||||
```python
|
||||
SECTOR_ETF_MAP: dict[str, str] = {
|
||||
"Technology": "XLK",
|
||||
"Consumer Cyclical": "XLY",
|
||||
"Financial Services": "XLF",
|
||||
"Healthcare": "XLV",
|
||||
"Energy": "XLE",
|
||||
"Communication Services": "XLC",
|
||||
"Industrials": "XLI",
|
||||
"Consumer Defensive": "XLP",
|
||||
"Real Estate": "XLRE",
|
||||
"Utilities": "XLU",
|
||||
}
|
||||
|
||||
EVALUATION_HORIZONS: list[str] = ["1h", "6h", "1d", "7d", "30d"]
|
||||
|
||||
MAX_SINGLE_DOCUMENT_WEIGHT: float = 1.0
|
||||
|
||||
|
||||
@dataclass
|
||||
class PredictionSnapshot:
|
||||
"""Immutable snapshot of a prediction at generation time."""
|
||||
id: str # UUID
|
||||
generated_at: datetime
|
||||
ticker: str
|
||||
window: str
|
||||
horizon: str
|
||||
direction: str # bullish/bearish/mixed/neutral
|
||||
action: str # buy/sell/hold/watch
|
||||
mode: str # informational/paper_eligible/live_eligible
|
||||
strength: float
|
||||
confidence: float
|
||||
contradiction: float
|
||||
p_bull: float | None
|
||||
p_bear: float | None
|
||||
score_company: float
|
||||
score_macro: float
|
||||
score_competitive: float
|
||||
evidence_count: int
|
||||
unique_source_count: int
|
||||
duplicate_evidence_count: int
|
||||
price_at_prediction: float | None
|
||||
spy_price_at_prediction: float | None
|
||||
sector_etf_price_at_prediction: float | None
|
||||
metadata: dict
|
||||
|
||||
|
||||
@dataclass
|
||||
class SignalEvidenceLink:
|
||||
"""Link between a prediction and a contributing evidence document."""
|
||||
id: str # UUID
|
||||
prediction_id: str
|
||||
document_id: str
|
||||
signal_id: str
|
||||
ticker: str
|
||||
source: str
|
||||
source_type: str
|
||||
catalyst_type: str
|
||||
sentiment: str
|
||||
impact: float
|
||||
extraction_confidence: float
|
||||
weight: float # clamped to MAX_SINGLE_DOCUMENT_WEIGHT
|
||||
is_duplicate: bool
|
||||
canonical_evidence_key: str
|
||||
contribution_score: float # weight / total_weight, sums to 1.0
|
||||
metadata: dict
|
||||
|
||||
|
||||
def compute_canonical_evidence_key(title: str, url: str) -> str:
|
||||
"""SHA256 of normalized(title) + normalized(url).
|
||||
|
||||
Normalization: lowercase, strip whitespace for title;
|
||||
lowercase, strip query params for URL.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
async def create_prediction_snapshot(
|
||||
pool: asyncpg.Pool,
|
||||
recommendation: Recommendation,
|
||||
trend_summary: TrendSummary,
|
||||
evidence_signals: list[WeightedSignal],
|
||||
evidence_docs: list[dict], # document metadata from recommendation_evidence
|
||||
) -> PredictionSnapshot:
|
||||
"""Create and persist a prediction snapshot with evidence links.
|
||||
|
||||
1. Fetches current prices (ticker, SPY, sector ETF) from market_snapshots
|
||||
2. Computes canonical evidence keys and duplicate detection
|
||||
3. Clamps individual document weights to MAX_SINGLE_DOCUMENT_WEIGHT
|
||||
4. Computes contribution scores (one-vote-per-canonical-key dedup)
|
||||
5. Persists snapshot and evidence links in a transaction
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
async def fetch_latest_close_price(
|
||||
pool: asyncpg.Pool,
|
||||
ticker: str,
|
||||
) -> float | None:
|
||||
"""Fetch most recent close price from market_snapshots for a ticker."""
|
||||
...
|
||||
```
|
||||
|
||||
#### 2. Outcome Evaluator (`services/validation/outcome_evaluator.py`)
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class PredictionOutcome:
|
||||
"""Realized outcome for a prediction at a specific horizon."""
|
||||
id: str # UUID
|
||||
prediction_id: str
|
||||
evaluated_at: datetime
|
||||
horizon: str # 1h, 6h, 1d, 7d, 30d
|
||||
future_price: float
|
||||
future_return: float
|
||||
spy_future_price: float | None
|
||||
spy_return: float | None
|
||||
sector_etf_future_price: float | None
|
||||
sector_etf_return: float | None
|
||||
excess_return_vs_spy: float | None
|
||||
excess_return_vs_sector: float | None
|
||||
direction_correct: bool
|
||||
profitable: bool
|
||||
metadata: dict
|
||||
|
||||
|
||||
HORIZON_DURATIONS: dict[str, timedelta] = {
|
||||
"1h": timedelta(hours=1),
|
||||
"6h": timedelta(hours=6),
|
||||
"1d": timedelta(days=1),
|
||||
"7d": timedelta(days=7),
|
||||
"30d": timedelta(days=30),
|
||||
}
|
||||
|
||||
|
||||
async def evaluate_matured_predictions(
|
||||
pool: asyncpg.Pool,
|
||||
) -> int:
|
||||
"""Evaluate all matured prediction snapshots.
|
||||
|
||||
Finds snapshots where horizon has elapsed and outcome not yet recorded.
|
||||
For each, fetches future prices and computes returns.
|
||||
Skips horizons where future price is unavailable (retries next run).
|
||||
|
||||
Returns count of outcomes recorded.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
async def evaluate_single_prediction(
|
||||
pool: asyncpg.Pool,
|
||||
snapshot: PredictionSnapshot,
|
||||
horizon: str,
|
||||
) -> PredictionOutcome | None:
|
||||
"""Evaluate a single prediction at a specific horizon.
|
||||
|
||||
Returns None if future price is unavailable.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### 3. Metrics Engine (`services/validation/metrics.py`)
|
||||
|
||||
```python
|
||||
CONFIDENCE_BUCKETS: list[tuple[float, float]] = [
|
||||
(0.50, 0.60),
|
||||
(0.60, 0.70),
|
||||
(0.70, 0.80),
|
||||
(0.80, 0.90),
|
||||
(0.90, 1.00),
|
||||
]
|
||||
|
||||
LOOKBACK_WINDOWS: list[str] = ["7d", "30d", "90d", "all"]
|
||||
|
||||
|
||||
@dataclass
|
||||
class CalibrationBucket:
|
||||
"""Calibration metrics for a single confidence bucket."""
|
||||
bucket_low: float
|
||||
bucket_high: float
|
||||
avg_confidence: float
|
||||
observed_win_rate: float
|
||||
prediction_count: int
|
||||
miscalibrated: bool # |avg_confidence - win_rate| > 0.15
|
||||
|
||||
|
||||
@dataclass
|
||||
class ModelMetricSnapshot:
|
||||
"""Aggregate model quality metrics for a lookback/horizon combination."""
|
||||
id: str
|
||||
generated_at: datetime
|
||||
lookback_window: str
|
||||
horizon: str
|
||||
prediction_count: int
|
||||
win_rate: float
|
||||
directional_accuracy: float
|
||||
information_coefficient: float | None
|
||||
rank_information_coefficient: float | None
|
||||
avg_return: float
|
||||
avg_excess_return_vs_spy: float
|
||||
avg_excess_return_vs_sector: float
|
||||
calibration_error: float # ECE
|
||||
brier_score: float
|
||||
buy_win_rate: float
|
||||
sell_win_rate: float
|
||||
hold_win_rate: float
|
||||
metadata: dict
|
||||
|
||||
|
||||
def compute_calibration_error(
|
||||
confidences: list[float],
|
||||
outcomes: list[bool],
|
||||
) -> tuple[float, list[CalibrationBucket]]:
|
||||
"""Compute ECE and calibration buckets.
|
||||
|
||||
ECE = Σ (n_b / N) * |avg_conf_b - win_rate_b|
|
||||
|
||||
Returns (ece, buckets).
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def compute_brier_score(
|
||||
p_bulls: list[float],
|
||||
outcomes: list[bool],
|
||||
) -> float:
|
||||
"""Brier score = mean((p_bull - outcome)^2).
|
||||
|
||||
outcome is 1.0 when price moved in predicted direction, 0.0 otherwise.
|
||||
Returns value in [0.0, 1.0].
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def compute_information_coefficient(
|
||||
scores: list[float],
|
||||
returns: list[float],
|
||||
) -> float | None:
|
||||
"""Pearson correlation between prediction scores and future returns.
|
||||
|
||||
Returns None when fewer than 30 data points.
|
||||
Returns value in [-1.0, 1.0].
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def compute_rank_information_coefficient(
|
||||
scores: list[float],
|
||||
returns: list[float],
|
||||
) -> float | None:
|
||||
"""Spearman rank correlation between prediction scores and future returns.
|
||||
|
||||
Returns None when fewer than 30 data points.
|
||||
Returns value in [-1.0, 1.0].
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def compute_contribution_scores(
|
||||
weights: list[float],
|
||||
) -> list[float]:
|
||||
"""Compute contribution scores from document weights.
|
||||
|
||||
Each score = weight_i / sum(weights). Sums to 1.0.
|
||||
Each score in [0.0, 1.0].
|
||||
Returns empty list for empty input.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
async def compute_and_store_metric_snapshots(
|
||||
pool: asyncpg.Pool,
|
||||
) -> list[ModelMetricSnapshot]:
|
||||
"""Compute metric snapshots for all lookback/horizon combinations.
|
||||
|
||||
Lookback windows: 7d, 30d, 90d, all-time.
|
||||
Horizons: 1h, 6h, 1d, 7d, 30d.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### 4. Attribution Engine (`services/validation/attribution.py`)
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class SourceAttribution:
|
||||
"""Performance metrics for a single source."""
|
||||
source: str
|
||||
source_type: str
|
||||
prediction_count: int
|
||||
avg_weight: float
|
||||
avg_contribution_score: float
|
||||
win_rate: float
|
||||
avg_future_return: float
|
||||
avg_excess_return_vs_spy: float
|
||||
information_coefficient: float | None
|
||||
duplicate_rate: float
|
||||
|
||||
|
||||
@dataclass
|
||||
class CatalystAttribution:
|
||||
"""Performance metrics for a single catalyst type."""
|
||||
catalyst_type: str
|
||||
prediction_count: int
|
||||
win_rate: float
|
||||
avg_future_return: float
|
||||
avg_excess_return_vs_spy: float
|
||||
information_coefficient: float | None
|
||||
|
||||
|
||||
@dataclass
|
||||
class LayerAttribution:
|
||||
"""Performance metrics for a signal layer."""
|
||||
layer: str # company, macro, competitive
|
||||
avg_contribution_pct: float
|
||||
dominant_win_rate: float # win rate when this layer > 30% contribution
|
||||
dominant_ic: float | None # IC when this layer > 30% contribution
|
||||
|
||||
|
||||
async def compute_source_attribution(
|
||||
pool: asyncpg.Pool,
|
||||
lookback_days: int = 30,
|
||||
horizon: str = "7d",
|
||||
) -> list[SourceAttribution]:
|
||||
...
|
||||
|
||||
|
||||
async def compute_catalyst_attribution(
|
||||
pool: asyncpg.Pool,
|
||||
lookback_days: int = 30,
|
||||
horizon: str = "7d",
|
||||
) -> list[CatalystAttribution]:
|
||||
...
|
||||
|
||||
|
||||
async def compute_layer_attribution(
|
||||
pool: asyncpg.Pool,
|
||||
lookback_days: int = 30,
|
||||
horizon: str = "7d",
|
||||
) -> list[LayerAttribution]:
|
||||
...
|
||||
```
|
||||
|
||||
#### 5. Calibration Engine (`services/validation/calibration.py`)
|
||||
|
||||
```python
|
||||
def compute_source_reliability(
|
||||
observed_win_rate: float,
|
||||
sample_count: int,
|
||||
prior_strength: int = 30,
|
||||
) -> float:
|
||||
"""Bayesian shrinkage source reliability.
|
||||
|
||||
reliability = 0.5 + (n / (n + prior_strength)) * (observed_win_rate - 0.5)
|
||||
|
||||
Returns value in [0.0, 1.0].
|
||||
When n=0, returns 0.5 (prior mean).
|
||||
As n→∞, approaches observed_win_rate.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def compute_adjusted_evidence_weight(
|
||||
base_weight: float,
|
||||
reliability: float,
|
||||
) -> float:
|
||||
"""Adjusted weight = base_weight * (0.5 + reliability), clamped to [0.1, 2.0]."""
|
||||
...
|
||||
|
||||
|
||||
async def update_source_reliabilities(
|
||||
pool: asyncpg.Pool,
|
||||
) -> int:
|
||||
"""Recompute and store source reliability scores from latest outcomes.
|
||||
|
||||
Uses the existing source_accuracy table, updating accuracy_ratio
|
||||
with the Bayesian shrinkage formula.
|
||||
|
||||
Returns count of sources updated.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### 6. Quality Gate (`services/trading/model_quality_gate.py`)
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class QualityGateConfig:
|
||||
"""Configurable thresholds for live trading eligibility."""
|
||||
min_prediction_count: int = 100
|
||||
min_ic: float = 0.03
|
||||
min_win_rate: float = 0.53
|
||||
max_ece: float = 0.15
|
||||
min_excess_return_vs_spy: float = 0.0
|
||||
max_snapshot_age_hours: int = 24
|
||||
|
||||
|
||||
@dataclass
|
||||
class GateThresholdResult:
|
||||
"""Result for a single threshold check."""
|
||||
name: str
|
||||
threshold: float
|
||||
actual: float
|
||||
passed: bool
|
||||
|
||||
|
||||
@dataclass
|
||||
class QualityGateResult:
|
||||
"""Full gate evaluation result."""
|
||||
passed: bool
|
||||
evaluated_at: datetime
|
||||
threshold_results: list[GateThresholdResult]
|
||||
reason: str # "all thresholds met" or "failed: ..."
|
||||
snapshot_id: str | None
|
||||
config: QualityGateConfig
|
||||
|
||||
|
||||
async def evaluate_quality_gate(
|
||||
pool: asyncpg.Pool,
|
||||
config: QualityGateConfig | None = None,
|
||||
) -> QualityGateResult:
|
||||
"""Evaluate model quality gate from latest metric snapshot.
|
||||
|
||||
Reads the most recent model_metric_snapshot for the 30d lookback
|
||||
and 7d horizon (the primary evaluation window).
|
||||
|
||||
If no snapshot exists or snapshot is stale (>24h), defaults to
|
||||
paper-only mode (fail-safe).
|
||||
|
||||
Stores result in risk_configs under 'model_quality_gate' key.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
async def load_gate_config_from_db(
|
||||
pool: asyncpg.Pool,
|
||||
) -> QualityGateConfig:
|
||||
"""Load gate thresholds from risk_configs, with defaults."""
|
||||
...
|
||||
```
|
||||
|
||||
#### 7. Dashboard API Endpoints
|
||||
|
||||
Seven new endpoints added to `services/api/app.py`:
|
||||
|
||||
| Endpoint | Method | Returns |
|
||||
|----------|--------|---------|
|
||||
| `/api/validation/summary` | GET | Latest model metric snapshot + gate status |
|
||||
| `/api/validation/calibration` | GET | Calibration table with buckets |
|
||||
| `/api/validation/ic-by-horizon` | GET | IC and Rank IC per horizon |
|
||||
| `/api/validation/attribution/sources` | GET | Per-source performance |
|
||||
| `/api/validation/attribution/catalysts` | GET | Per-catalyst performance |
|
||||
| `/api/validation/attribution/layers` | GET | Per-layer performance |
|
||||
| `/api/validation/gate-status` | GET | Quality gate evaluation detail |
|
||||
|
||||
All endpoints accept optional `lookback` (default "30d") and `horizon` (default "7d") query parameters.
|
||||
|
||||
---
|
||||
|
||||
## Data Models
|
||||
|
||||
### Database Schema (Migration 035)
|
||||
|
||||
#### prediction_snapshots
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS prediction_snapshots (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
generated_at TIMESTAMPTZ NOT NULL,
|
||||
ticker VARCHAR(20) NOT NULL,
|
||||
window VARCHAR(20) NOT NULL,
|
||||
horizon VARCHAR(20) NOT NULL,
|
||||
direction VARCHAR(20) NOT NULL,
|
||||
action VARCHAR(20) NOT NULL,
|
||||
mode VARCHAR(30) NOT NULL,
|
||||
strength FLOAT NOT NULL,
|
||||
confidence FLOAT NOT NULL,
|
||||
contradiction FLOAT NOT NULL DEFAULT 0.0,
|
||||
p_bull FLOAT,
|
||||
p_bear FLOAT,
|
||||
score_company FLOAT NOT NULL DEFAULT 0.0,
|
||||
score_macro FLOAT NOT NULL DEFAULT 0.0,
|
||||
score_competitive FLOAT NOT NULL DEFAULT 0.0,
|
||||
evidence_count INTEGER NOT NULL DEFAULT 0,
|
||||
unique_source_count INTEGER NOT NULL DEFAULT 0,
|
||||
duplicate_evidence_count INTEGER NOT NULL DEFAULT 0,
|
||||
price_at_prediction FLOAT,
|
||||
spy_price_at_prediction FLOAT,
|
||||
sector_etf_price_at_prediction FLOAT,
|
||||
metadata JSONB DEFAULT '{}',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_snap_ticker ON prediction_snapshots(ticker);
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_snap_generated ON prediction_snapshots(generated_at);
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_snap_horizon ON prediction_snapshots(horizon);
|
||||
```
|
||||
|
||||
#### prediction_outcomes
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS prediction_outcomes (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
prediction_id UUID NOT NULL REFERENCES prediction_snapshots(id),
|
||||
evaluated_at TIMESTAMPTZ NOT NULL,
|
||||
horizon VARCHAR(20) NOT NULL,
|
||||
future_price FLOAT,
|
||||
future_return FLOAT,
|
||||
spy_future_price FLOAT,
|
||||
spy_return FLOAT,
|
||||
sector_etf_future_price FLOAT,
|
||||
sector_etf_return FLOAT,
|
||||
excess_return_vs_spy FLOAT,
|
||||
excess_return_vs_sector FLOAT,
|
||||
direction_correct BOOLEAN,
|
||||
profitable BOOLEAN,
|
||||
metadata JSONB DEFAULT '{}',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_out_prediction ON prediction_outcomes(prediction_id);
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_out_horizon ON prediction_outcomes(horizon);
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_out_evaluated ON prediction_outcomes(evaluated_at);
|
||||
```
|
||||
|
||||
#### signal_evidence_links
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS signal_evidence_links (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
prediction_id UUID NOT NULL REFERENCES prediction_snapshots(id),
|
||||
document_id VARCHAR(200),
|
||||
signal_id VARCHAR(200),
|
||||
ticker VARCHAR(20),
|
||||
source VARCHAR(200),
|
||||
source_type VARCHAR(50),
|
||||
catalyst_type VARCHAR(50),
|
||||
sentiment VARCHAR(20),
|
||||
impact FLOAT,
|
||||
extraction_confidence FLOAT,
|
||||
weight FLOAT,
|
||||
is_duplicate BOOLEAN NOT NULL DEFAULT FALSE,
|
||||
canonical_evidence_key VARCHAR(64),
|
||||
contribution_score FLOAT,
|
||||
metadata JSONB DEFAULT '{}',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_sig_ev_prediction ON signal_evidence_links(prediction_id);
|
||||
CREATE INDEX IF NOT EXISTS idx_sig_ev_document ON signal_evidence_links(document_id);
|
||||
CREATE INDEX IF NOT EXISTS idx_sig_ev_ticker ON signal_evidence_links(ticker);
|
||||
```
|
||||
|
||||
#### model_metric_snapshots
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS model_metric_snapshots (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
generated_at TIMESTAMPTZ NOT NULL,
|
||||
lookback_window VARCHAR(20) NOT NULL,
|
||||
horizon VARCHAR(20) NOT NULL,
|
||||
prediction_count INTEGER NOT NULL DEFAULT 0,
|
||||
win_rate FLOAT,
|
||||
directional_accuracy FLOAT,
|
||||
information_coefficient FLOAT,
|
||||
rank_information_coefficient FLOAT,
|
||||
avg_return FLOAT,
|
||||
avg_excess_return_vs_spy FLOAT,
|
||||
avg_excess_return_vs_sector FLOAT,
|
||||
calibration_error FLOAT,
|
||||
brier_score FLOAT,
|
||||
buy_win_rate FLOAT,
|
||||
sell_win_rate FLOAT,
|
||||
hold_win_rate FLOAT,
|
||||
metadata JSONB DEFAULT '{}',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_model_snap_generated ON model_metric_snapshots(generated_at);
|
||||
CREATE INDEX IF NOT EXISTS idx_model_snap_lookback ON model_metric_snapshots(lookback_window);
|
||||
CREATE INDEX IF NOT EXISTS idx_model_snap_horizon ON model_metric_snapshots(horizon);
|
||||
```
|
||||
|
||||
#### SQL Explorer Views
|
||||
|
||||
```sql
|
||||
CREATE OR REPLACE VIEW v_prediction_performance AS
|
||||
SELECT
|
||||
ps.ticker,
|
||||
ps.direction,
|
||||
ps.action,
|
||||
ps.confidence,
|
||||
ps.strength,
|
||||
ps.contradiction,
|
||||
ps.p_bull,
|
||||
ps.score_company,
|
||||
ps.score_macro,
|
||||
ps.score_competitive,
|
||||
ps.evidence_count,
|
||||
ps.unique_source_count,
|
||||
ps.duplicate_evidence_count,
|
||||
ps.price_at_prediction,
|
||||
po.future_return,
|
||||
po.excess_return_vs_spy,
|
||||
po.excess_return_vs_sector,
|
||||
po.direction_correct,
|
||||
po.profitable,
|
||||
po.horizon,
|
||||
ps.generated_at,
|
||||
po.evaluated_at
|
||||
FROM prediction_snapshots ps
|
||||
JOIN prediction_outcomes po ON po.prediction_id = ps.id;
|
||||
|
||||
CREATE OR REPLACE VIEW v_source_performance AS
|
||||
SELECT
|
||||
sel.source,
|
||||
sel.source_type,
|
||||
sel.catalyst_type,
|
||||
sel.sentiment,
|
||||
sel.weight,
|
||||
sel.contribution_score,
|
||||
sel.is_duplicate,
|
||||
po.direction_correct,
|
||||
po.future_return,
|
||||
po.excess_return_vs_spy,
|
||||
po.horizon,
|
||||
ps.generated_at
|
||||
FROM signal_evidence_links sel
|
||||
JOIN prediction_snapshots ps ON ps.id = sel.prediction_id
|
||||
JOIN prediction_outcomes po ON po.prediction_id = sel.prediction_id;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Correctness Properties
|
||||
|
||||
*A property is a characteristic or behavior that should hold true across all valid executions of a system — essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
|
||||
|
||||
The following properties were derived from the acceptance criteria through systematic prework analysis. Each property is universally quantified and maps to specific requirements. After reflection, 7 unique properties remain — one for each PBT requirement in Requirement 17. Redundant properties from Requirements 2, 5, 6, 8, and 11 were consolidated with their corresponding Requirement 17 counterparts.
|
||||
|
||||
### Property 1: Calibration Error Range and Round-Trip
|
||||
|
||||
*For any* valid distribution of predictions across confidence buckets (where each prediction has a confidence in [0.5, 1.0] and a boolean outcome), the Expected Calibration Error (ECE) SHALL be in [0.0, 1.0]. Furthermore, when every bucket's observed win rate exactly matches its average confidence, ECE SHALL be 0.0.
|
||||
|
||||
**Validates: Requirements 5.1, 5.3, 17.1**
|
||||
|
||||
### Property 2: Brier Score Range and Perfect Prediction
|
||||
|
||||
*For any* list of (p_bull, outcome) pairs where p_bull ∈ [0.0, 1.0] and outcome ∈ {0.0, 1.0}, the Brier score SHALL be in [0.0, 1.0]. Furthermore, when all predictions have p_bull = 1.0 and outcome = 1.0 (or p_bull = 0.0 and outcome = 0.0), the Brier score SHALL be 0.0.
|
||||
|
||||
**Validates: Requirements 5.4, 17.2**
|
||||
|
||||
### Property 3: Information Coefficient Range and Perfect Correlation
|
||||
|
||||
*For any* list of (score, return) pairs with at least 30 elements where scores and returns are finite floats, the Information Coefficient (Pearson correlation) SHALL be in [-1.0, 1.0]. Furthermore, when scores and returns are perfectly positively linearly correlated (returns = a * scores + b, a > 0), IC SHALL be 1.0 (within floating-point tolerance).
|
||||
|
||||
**Validates: Requirements 6.1, 6.2, 17.3**
|
||||
|
||||
### Property 4: Canonical Evidence Key Determinism and Normalization Idempotence
|
||||
|
||||
*For any* (title, url) string pair, computing the canonical evidence key SHALL be deterministic — the same inputs always produce the same key. Furthermore, normalizing an already-normalized input (lowercased, trimmed title; lowercased, query-stripped URL) and computing the key SHALL produce the same key as the original computation (idempotence).
|
||||
|
||||
**Validates: Requirements 2.3, 17.4**
|
||||
|
||||
### Property 5: Source Reliability Bayesian Shrinkage Bounds and Convergence
|
||||
|
||||
*For any* observed_win_rate ∈ [0.0, 1.0] and sample_count ≥ 0, the source reliability computed via Bayesian shrinkage SHALL be in [0.0, 1.0]. When sample_count = 0, reliability SHALL be exactly 0.5. As sample_count increases toward infinity, reliability SHALL approach the observed_win_rate monotonically.
|
||||
|
||||
**Validates: Requirements 8.1, 8.2, 17.5**
|
||||
|
||||
### Property 6: Quality Gate Determinism and Threshold Monotonicity
|
||||
|
||||
*For any* set of model metric values and quality gate configuration, the gate evaluation result SHALL be deterministic — the same inputs always produce the same pass/fail result. Furthermore, for any configuration where the gate passes, relaxing any single threshold (increasing min values or decreasing max values to make them easier to satisfy) SHALL NOT cause the gate to fail (monotonicity).
|
||||
|
||||
**Validates: Requirements 11.1, 17.6**
|
||||
|
||||
### Property 7: Contribution Score Sum-to-One and Range
|
||||
|
||||
*For any* non-empty list of positive document weights, the computed contribution scores SHALL each be in [0.0, 1.0] and SHALL sum to 1.0 (within floating-point tolerance of 1e-9). For an empty weight list, the result SHALL be an empty list.
|
||||
|
||||
**Validates: Requirements 2.5, 17.7**
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Price Data Unavailability
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| Ticker price unavailable at snapshot time | Store NULL for `price_at_prediction`, log warning, continue |
|
||||
| SPY price unavailable at snapshot time | Store NULL for `spy_price_at_prediction`, log warning, continue |
|
||||
| Sector ETF price unavailable at snapshot time | Store NULL for `sector_etf_price_at_prediction`, log warning, continue |
|
||||
| Sector not found in SECTOR_ETF_MAP | Store NULL for sector ETF price, log warning |
|
||||
| Future price unavailable at evaluation time | Skip that horizon, retry on next Outcome_Evaluator run |
|
||||
| SPY/sector ETF future price unavailable | Store NULL for excess returns, still compute ticker return |
|
||||
|
||||
### Metrics Computation Edge Cases
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| Zero predictions in a confidence bucket | Exclude bucket from ECE computation |
|
||||
| Fewer than 30 predictions for IC/Rank IC | Return NULL instead of unreliable correlation |
|
||||
| All predictions in same confidence bucket | ECE = |avg_confidence - win_rate| for that single bucket |
|
||||
| Division by zero in contribution scores (total weight = 0) | Return equal contribution scores (1/n) |
|
||||
| Single prediction | Contribution score = 1.0 |
|
||||
| NaN/infinity in metric computation | Guard with `math.isnan`/`math.isinf` checks, return 0.0 or NULL |
|
||||
|
||||
### Quality Gate Failures
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| No model_metric_snapshots exist | Default to paper-only mode (fail-safe) |
|
||||
| Most recent snapshot older than 24 hours | Default to paper-only mode (fail-safe) |
|
||||
| risk_configs table unreachable | Default to paper-only mode, log warning |
|
||||
| Invalid threshold values in risk_configs | Use default thresholds, log warning |
|
||||
| Gate evaluation fails mid-computation | Default to paper-only mode, log error |
|
||||
|
||||
### Database Failures
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| prediction_snapshots insert fails | Log error, do not block recommendation generation |
|
||||
| signal_evidence_links insert fails | Log error, snapshot still created (partial data) |
|
||||
| prediction_outcomes insert fails | Log error, retry on next Outcome_Evaluator run |
|
||||
| model_metric_snapshots insert fails | Log error, stale metrics used until next successful computation |
|
||||
| source_accuracy update fails | Log error, continue with stale reliability data |
|
||||
|
||||
### Canonical Evidence Key Edge Cases
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| Empty title | Use empty string in hash computation |
|
||||
| Empty URL | Use empty string in hash computation |
|
||||
| URL with no query parameters | Use URL as-is after lowercasing |
|
||||
| Non-ASCII characters in title/URL | Encode as UTF-8 before hashing |
|
||||
|
||||
---
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Dual Testing Approach
|
||||
|
||||
The model validation feature requires both property-based tests (for mathematical correctness of metric computations) and example-based unit tests (for specific behaviors, integration points, and edge cases). Property-based testing is appropriate here because the feature contains several pure mathematical functions (ECE, Brier score, IC, Bayesian shrinkage, contribution scores) with clear input/output behavior and universal properties.
|
||||
|
||||
### Property-Based Testing
|
||||
|
||||
**Library:** Hypothesis (already in use — `.hypothesis/` directory exists, project convention established)
|
||||
|
||||
**Configuration:**
|
||||
- Minimum 100 iterations per property: `@settings(max_examples=100)`
|
||||
- File naming: `tests/test_pbt_model_validation.py`
|
||||
- Tag format: `# Feature: model-validation-calibration, Property N: <title>`
|
||||
|
||||
**Property tests to implement (one test per correctness property):**
|
||||
|
||||
| Property | Test Function | Key Generators |
|
||||
|----------|---------------|----------------|
|
||||
| 1: ECE range and round-trip | `test_calibration_error_range_and_roundtrip` | `st.lists(st.tuples(st.floats(0.5, 1.0), st.booleans()))` |
|
||||
| 2: Brier score range and perfect | `test_brier_score_range_and_perfect` | `st.lists(st.tuples(st.floats(0.0, 1.0), st.sampled_from([0.0, 1.0])))` |
|
||||
| 3: IC range and perfect correlation | `test_information_coefficient_range_and_perfect` | `st.lists(st.floats(-10, 10), min_size=30)` with linear transform |
|
||||
| 4: Canonical key determinism and idempotence | `test_canonical_key_determinism_and_idempotence` | `st.text()` pairs for title and URL |
|
||||
| 5: Source reliability bounds and convergence | `test_source_reliability_bounds_and_convergence` | `st.floats(0.0, 1.0)` for win_rate, `st.integers(0, 10000)` for n |
|
||||
| 6: Quality gate determinism and monotonicity | `test_quality_gate_determinism_and_monotonicity` | Custom strategy for `QualityGateConfig` and metric values |
|
||||
| 7: Contribution score sum-to-one | `test_contribution_score_sum_to_one` | `st.lists(st.floats(0.01, 100.0), min_size=1)` |
|
||||
|
||||
### Example-Based Unit Tests
|
||||
|
||||
**File:** `tests/test_model_validation_unit.py`
|
||||
|
||||
| Test Area | Examples |
|
||||
|-----------|----------|
|
||||
| Canonical evidence key | Known title/URL → expected SHA256, empty inputs, unicode |
|
||||
| Duplicate detection | 3 docs with 2 sharing a key → 1 marked duplicate |
|
||||
| Contribution scores | [0.5, 0.3, 0.2] → [0.5, 0.3, 0.2], single doc → [1.0] |
|
||||
| ECE specific values | Perfect calibration → 0.0, all overconfident → positive ECE |
|
||||
| Brier score specific values | All correct at p=1.0 → 0.0, all wrong at p=1.0 → 1.0 |
|
||||
| IC specific values | Perfect correlation → 1.0, anti-correlation → -1.0, < 30 → None |
|
||||
| Source reliability | n=0 → 0.5, n=1000 with wr=0.8 → ≈0.8, n=30 with wr=0.7 → 0.6 |
|
||||
| Adjusted evidence weight | reliability=0.5 → base*1.0, clamping to [0.1, 2.0] |
|
||||
| Quality gate | All thresholds met → pass, one failed → fail with reason |
|
||||
| Quality gate fail-safe | No snapshots → paper-only, stale snapshot → paper-only |
|
||||
| Direction correct logic | bullish+positive → true, bullish+negative → false |
|
||||
| Profitable logic | buy+positive → true, sell+negative → true |
|
||||
| Future return computation | price 100→110 → 0.10, price 100→90 → -0.10 |
|
||||
| Excess return | ticker 10%, SPY 5% → excess 5% |
|
||||
| Weight clamping | weight 1.5 → clamped to 1.0 |
|
||||
|
||||
### Frontend Tests
|
||||
|
||||
**File:** `frontend/src/test/pages.test.tsx` (extend existing)
|
||||
|
||||
| Test Area | Strategy |
|
||||
|-----------|----------|
|
||||
| OpsModel page renders validation tabs | MSW mock for `/api/validation/summary` |
|
||||
| Calibration table renders buckets | MSW mock for `/api/validation/calibration` |
|
||||
| Gate status indicator | MSW mock for `/api/validation/gate-status` |
|
||||
| Miscalibration warning badge | Mock data with miscalibrated bucket |
|
||||
|
||||
### Integration Tests
|
||||
|
||||
**File:** `tests/test_model_validation_integration.py`
|
||||
|
||||
| Test Area | Strategy |
|
||||
|-----------|----------|
|
||||
| Snapshot creation with mock DB | asyncpg mock, verify INSERT queries |
|
||||
| Outcome evaluation with mock prices | asyncpg mock, verify return computation |
|
||||
| Metrics computation end-to-end | In-memory data, verify all metrics computed |
|
||||
| API endpoint responses | FastAPI TestClient with mock pool |
|
||||
|
||||
### Test File Structure
|
||||
|
||||
```
|
||||
tests/
|
||||
├── test_pbt_model_validation.py # 7 property-based tests
|
||||
├── test_model_validation_unit.py # Example-based unit tests
|
||||
└── test_model_validation_integration.py # Integration tests (optional)
|
||||
|
||||
frontend/src/test/
|
||||
└── pages.test.tsx # Extended with validation page tests
|
||||
```
|
||||
@@ -0,0 +1,286 @@
|
||||
# Requirements Document — Model Validation, Calibration, and Signal Quality
|
||||
|
||||
## Introduction
|
||||
|
||||
The Stonks Oracle platform generates trend summaries and trading recommendations from a three-layer signal aggregation engine. While the pipeline produces directional predictions with confidence scores, there is no systematic mechanism to evaluate whether those predictions are accurate, whether confidence scores are well-calibrated, which sources and signal types contribute to correct predictions, or whether the system outperforms simple benchmarks. The platform also lacks safety gates that prevent live trading when model quality is insufficient.
|
||||
|
||||
This feature adds a complete model validation layer: prediction outcome tracking, calibration analysis, information coefficient metrics, signal and source attribution, evidence deduplication quality tracking, confidence recalibration, benchmark comparison, an upgraded Model Performance dashboard, and safety gates for live trading eligibility. The goal is to transform Stonks Oracle from a signal dashboard with paper trading into a statistically validated prediction engine with closed-loop feedback.
|
||||
|
||||
## Glossary
|
||||
|
||||
- **Prediction_Snapshot_Writer**: A new service component in `services/validation/prediction_snapshot.py` that captures the full state of every recommendation and trend prediction at generation time, including prices, evidence links, and duplicate counts.
|
||||
- **Outcome_Evaluator**: A new service component in `services/validation/outcome_evaluator.py` that runs periodically to compute realized future returns and directional accuracy for matured prediction snapshots across multiple horizons.
|
||||
- **Metrics_Engine**: A new service component in `services/validation/metrics.py` that computes aggregate model quality metrics including calibration error, information coefficient, Brier score, and win rates over configurable lookback windows.
|
||||
- **Attribution_Engine**: A new service component in `services/validation/attribution.py` that computes per-source, per-catalyst-type, and per-signal-layer performance metrics by joining evidence links with prediction outcomes.
|
||||
- **Calibration_Engine**: A new service component in `services/validation/calibration.py` that computes source reliability scores using Bayesian shrinkage and adjusts evidence weights based on historical source performance.
|
||||
- **Quality_Gate**: A new service component in `services/trading/model_quality_gate.py` that evaluates aggregate model metrics against configurable thresholds and determines whether the system meets minimum quality standards for live trading.
|
||||
- **Information_Coefficient**: The Pearson correlation between predicted scores and realized future returns, measuring the linear predictive power of the model. Abbreviated as IC.
|
||||
- **Rank_Information_Coefficient**: The Spearman rank correlation between predicted scores and realized future returns, measuring ordinal predictive power. Abbreviated as Rank IC.
|
||||
- **Calibration_Error**: The Expected Calibration Error (ECE), computed as the weighted average of the absolute difference between predicted confidence and observed win rate across confidence buckets.
|
||||
- **Brier_Score**: The mean squared error between the predicted bullish probability and the binary actual outcome (1 if price went up, 0 otherwise), measuring probabilistic forecast accuracy.
|
||||
- **Canonical_Evidence_Key**: A normalized identifier for a piece of evidence, computed as SHA256 of the normalized title concatenated with the normalized URL, used to detect duplicate evidence across different ingestion paths.
|
||||
- **Excess_Return**: The return of a prediction minus the return of a benchmark (SPY for broad market, sector ETF for sector-relative) over the same horizon, measuring alpha generation.
|
||||
- **Prediction_Snapshot**: A frozen record of a prediction at generation time, capturing all inputs (prices, scores, evidence) needed to evaluate the prediction against future outcomes without hindsight bias.
|
||||
- **Model_Metric_Snapshot**: A periodic aggregate of model quality metrics over a lookback window and horizon, stored for time-series analysis of model performance trends.
|
||||
- **Source_Reliability**: A Bayesian-shrunk estimate of a source's historical win rate, computed as `0.5 + (n/(n+30)) * (observed_win_rate - 0.5)`, which regresses toward 0.5 for sources with few observations.
|
||||
- **Dashboard_API**: The set of API endpoints under `/api/validation/` that serve model quality metrics, calibration tables, attribution data, and gate status to the frontend.
|
||||
|
||||
---
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement 1: Prediction Snapshot Capture
|
||||
|
||||
**User Story:** As a quantitative analyst, I want every recommendation and trend prediction captured as an immutable snapshot at generation time, so that I can evaluate predictions against future outcomes without hindsight bias.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN a recommendation is generated by the Recommendation_Engine, THE Prediction_Snapshot_Writer SHALL create a prediction_snapshots record containing the ticker, generation timestamp, trend window, prediction horizon, direction, action, mode, strength, confidence, contradiction score, bullish probability, bearish probability, company score, macro score, competitive score, evidence count, unique source count, duplicate evidence count, price at prediction time, SPY price at prediction time, and sector ETF price at prediction time.
|
||||
2. WHEN a prediction snapshot is created, THE Prediction_Snapshot_Writer SHALL record the current market price for the predicted ticker by querying the most recent close price from the market_snapshots table.
|
||||
3. WHEN a prediction snapshot is created, THE Prediction_Snapshot_Writer SHALL record the current SPY price by querying the most recent close price for ticker SPY from the market_snapshots table.
|
||||
4. WHEN a prediction snapshot is created, THE Prediction_Snapshot_Writer SHALL record the current sector ETF price by looking up the sector for the predicted ticker and querying the most recent close price for the corresponding sector ETF from the market_snapshots table.
|
||||
5. IF the market price, SPY price, or sector ETF price is unavailable at snapshot time, THEN THE Prediction_Snapshot_Writer SHALL store NULL for the unavailable price fields and log a warning, rather than failing the snapshot creation.
|
||||
6. THE Prediction_Snapshot_Writer SHALL store prediction snapshots in a new `prediction_snapshots` database table with a UUID primary key and indexed columns for ticker, generated_at, and horizon.
|
||||
7. WHEN a prediction snapshot is created, THE Prediction_Snapshot_Writer SHALL store a JSONB metadata field containing any additional context from the trend summary market_context and recommendation risk_checks fields.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 2: Signal Evidence Link Tracking
|
||||
|
||||
**User Story:** As a quantitative analyst, I want to know which specific evidence documents contributed to each prediction, so that I can attribute prediction success or failure to individual sources and signal types.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN a prediction snapshot is created, THE Prediction_Snapshot_Writer SHALL create signal_evidence_links records for each document that contributed to the prediction, linking the prediction_id to the document_id and signal_id.
|
||||
2. THE signal_evidence_links record SHALL capture the source identifier, source type, catalyst type, sentiment, impact score, extraction confidence, weight assigned during aggregation, duplicate status, canonical evidence key, and contribution score for each contributing document.
|
||||
3. WHEN recording evidence links, THE Prediction_Snapshot_Writer SHALL compute the canonical_evidence_key as the SHA256 hash of the concatenation of the normalized (lowercased, whitespace-trimmed) document title and the normalized (lowercased, query-parameters-stripped) document URL.
|
||||
4. WHEN recording evidence links, THE Prediction_Snapshot_Writer SHALL mark a link as `is_duplicate = true` when another link for the same prediction and ticker shares the same canonical_evidence_key.
|
||||
5. THE Prediction_Snapshot_Writer SHALL compute the contribution_score for each evidence link as the ratio of that document's effective weight to the total effective weight across all documents for the prediction.
|
||||
6. THE signal_evidence_links table SHALL have a foreign key constraint from prediction_id to prediction_snapshots(id) and indexes on prediction_id, document_id, and ticker.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 3: Evidence Deduplication Quality Tracking
|
||||
|
||||
**User Story:** As a quantitative analyst, I want the system to track evidence deduplication quality per prediction, so that I can identify when predictions are inflated by counting the same information multiple times from different sources.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN creating a prediction snapshot, THE Prediction_Snapshot_Writer SHALL compute the unique_source_count as the number of distinct source identifiers across all non-duplicate evidence links for that prediction.
|
||||
2. WHEN creating a prediction snapshot, THE Prediction_Snapshot_Writer SHALL compute the duplicate_evidence_count as the number of evidence links marked as `is_duplicate = true` for that prediction.
|
||||
3. THE Prediction_Snapshot_Writer SHALL enforce a maximum single-document weight cap of 1.0, clamping any individual document's effective weight to prevent a single piece of evidence from dominating the prediction.
|
||||
4. WHEN computing contribution scores, THE Prediction_Snapshot_Writer SHALL count each canonical evidence key at most once per ticker per window, applying the one-vote-per-canonical-document deduplication rule.
|
||||
5. THE Metrics_Engine SHALL compute a duplicate_rate metric as the ratio of duplicate_evidence_count to total evidence_count across predictions in the lookback window.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 4: Prediction Outcome Evaluation
|
||||
|
||||
**User Story:** As a quantitative analyst, I want realized market outcomes automatically matched to historical predictions, so that I can measure whether the system's directional calls and confidence scores correspond to actual price movements.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Outcome_Evaluator SHALL run on a periodic schedule, evaluating prediction snapshots whose horizon has elapsed and whose outcome has not yet been recorded.
|
||||
2. WHEN evaluating a prediction snapshot, THE Outcome_Evaluator SHALL compute the future_return as `(future_price - price_at_prediction) / price_at_prediction` using the closing price at the horizon endpoint.
|
||||
3. WHEN evaluating a prediction snapshot, THE Outcome_Evaluator SHALL compute the SPY return over the same horizon as `(spy_future_price - spy_price_at_prediction) / spy_price_at_prediction`.
|
||||
4. WHEN evaluating a prediction snapshot, THE Outcome_Evaluator SHALL compute the sector ETF return over the same horizon as `(sector_etf_future_price - sector_etf_price_at_prediction) / sector_etf_price_at_prediction`.
|
||||
5. WHEN evaluating a prediction snapshot, THE Outcome_Evaluator SHALL compute excess_return_vs_spy as `future_return - spy_return` and excess_return_vs_sector as `future_return - sector_etf_return`.
|
||||
6. WHEN evaluating a prediction snapshot, THE Outcome_Evaluator SHALL determine direction_correct as true when the prediction direction is bullish and future_return is positive, or when the prediction direction is bearish and future_return is negative.
|
||||
7. WHEN evaluating a prediction snapshot, THE Outcome_Evaluator SHALL determine profitable as true when the prediction action is buy and future_return is positive, or when the prediction action is sell and future_return is negative.
|
||||
8. THE Outcome_Evaluator SHALL evaluate each prediction across all applicable horizons: 1 hour, 6 hours, 1 day, 7 days, and 30 days.
|
||||
9. THE Outcome_Evaluator SHALL store evaluation results in a new `prediction_outcomes` table with a foreign key to prediction_snapshots and indexed columns for prediction_id, horizon, and evaluated_at.
|
||||
10. IF the future price is unavailable at the horizon endpoint (market data gap), THEN THE Outcome_Evaluator SHALL skip that horizon evaluation and retry on the next run.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 5: Calibration Analysis
|
||||
|
||||
**User Story:** As a quantitative analyst, I want to measure how well the system's confidence scores predict actual win rates, so that I can identify overconfident or underconfident predictions and recalibrate the model.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Metrics_Engine SHALL compute calibration metrics by grouping evaluated predictions into confidence buckets: [0.50, 0.60), [0.60, 0.70), [0.70, 0.80), [0.80, 0.90), [0.90, 1.00].
|
||||
2. FOR EACH confidence bucket, THE Metrics_Engine SHALL compute the average confidence, the observed win rate (fraction of direction_correct outcomes), and the prediction count.
|
||||
3. THE Metrics_Engine SHALL compute the Expected Calibration Error (ECE) as the weighted average of `|avg_confidence - observed_win_rate|` across all buckets, weighted by the fraction of predictions in each bucket.
|
||||
4. THE Metrics_Engine SHALL compute the Brier Score as `mean((p_bull - actual_outcome)^2)` across all evaluated predictions, where actual_outcome is 1.0 when the price moved in the predicted direction and 0.0 otherwise.
|
||||
5. THE Metrics_Engine SHALL flag calibration buckets where `|avg_confidence - observed_win_rate| > 0.15` as miscalibrated for dashboard highlighting.
|
||||
6. THE Metrics_Engine SHALL compute calibration metrics separately for each prediction horizon (1h, 6h, 1d, 7d, 30d).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 6: Information Coefficient Metrics
|
||||
|
||||
**User Story:** As a quantitative analyst, I want to measure the correlation between the system's prediction scores and realized returns, so that I can assess whether higher-scored predictions actually produce higher returns.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Metrics_Engine SHALL compute the Information Coefficient (IC) as the Pearson correlation between prediction scores and future returns across all evaluated predictions in the lookback window.
|
||||
2. THE Metrics_Engine SHALL compute the Rank Information Coefficient (Rank IC) as the Spearman rank correlation between prediction scores and future returns across all evaluated predictions in the lookback window.
|
||||
3. THE Metrics_Engine SHALL compute IC and Rank IC separately for each prediction horizon (1h, 6h, 1d, 7d, 30d).
|
||||
4. THE Metrics_Engine SHALL compute return statistics by confidence decile, grouping predictions into 10 equal-sized bins by confidence and computing the average future return and average excess return for each decile.
|
||||
5. WHEN fewer than 30 evaluated predictions exist for a given horizon, THE Metrics_Engine SHALL report IC and Rank IC as NULL rather than computing unreliable correlations from small samples.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 7: Source and Signal Attribution
|
||||
|
||||
**User Story:** As a quantitative analyst, I want to know which sources, source types, and catalyst types contribute to accurate predictions, so that I can identify the most valuable information channels and deprioritize unreliable ones.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Attribution_Engine SHALL compute per-source performance metrics by joining signal_evidence_links with prediction_outcomes, grouping by source identifier.
|
||||
2. FOR EACH source, THE Attribution_Engine SHALL compute: prediction count, average weight, average contribution score, win rate, average future return, average excess return vs SPY, and information coefficient.
|
||||
3. THE Attribution_Engine SHALL compute the same performance metrics grouped by source_type (e.g., news_api, filings_api, web_scrape, market_api).
|
||||
4. THE Attribution_Engine SHALL compute the same performance metrics grouped by catalyst_type (e.g., earnings, product, legal, macro, m_and_a).
|
||||
5. THE Attribution_Engine SHALL compute layer attribution metrics for the three signal layers (company, macro, competitive) by using the score_company, score_macro, and score_competitive fields from prediction snapshots.
|
||||
6. FOR EACH layer, THE Attribution_Engine SHALL compute the average contribution percentage, the win rate when that layer is the dominant contributor, and the IC of predictions where that layer contributes more than 30% of the total score.
|
||||
7. THE Attribution_Engine SHALL compute a per-source duplicate_rate as the fraction of evidence links from that source marked as is_duplicate.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 8: Confidence Recalibration via Source Reliability
|
||||
|
||||
**User Story:** As a quantitative analyst, I want source credibility weights adjusted based on historical prediction accuracy using Bayesian shrinkage, so that the system learns from its own track record and improves over time.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Calibration_Engine SHALL compute source reliability using Bayesian shrinkage: `reliability = 0.5 + (n / (n + 30)) * (observed_win_rate - 0.5)`, where n is the number of evaluated predictions involving that source and observed_win_rate is the fraction of correct directional calls.
|
||||
2. WHEN a source has zero evaluated predictions, THE Calibration_Engine SHALL assign a reliability of 0.5 (the prior mean).
|
||||
3. THE Calibration_Engine SHALL compute an adjusted evidence weight for each source as `adjusted_weight = base_weight * (0.5 + reliability)`, clamped to the range [0.1, 2.0].
|
||||
4. THE Calibration_Engine SHALL update source reliability scores after each outcome evaluation cycle, using the latest prediction outcomes.
|
||||
5. THE Calibration_Engine SHALL store source reliability scores in the existing `source_accuracy` table, extending it with a reliability column or using the existing accuracy_ratio field with the Bayesian shrinkage formula.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 9: Benchmark Comparison
|
||||
|
||||
**User Story:** As a quantitative analyst, I want the system's prediction performance compared against simple benchmarks, so that I can determine whether the model adds value beyond naive strategies.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Metrics_Engine SHALL compute the average excess return of all buy predictions versus a buy-and-hold SPY strategy over the same horizons.
|
||||
2. THE Metrics_Engine SHALL compute the average excess return of all buy predictions versus a buy-and-hold sector ETF strategy over the same horizons.
|
||||
3. THE Metrics_Engine SHALL compute the win rate of the system's directional predictions compared to a random 50/50 baseline, reporting the statistical significance using a binomial test when the prediction count exceeds 100.
|
||||
4. THE Metrics_Engine SHALL compute the hit rate improvement, defined as `(system_win_rate - 0.5) / 0.5`, representing the percentage improvement over random guessing.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 10: Model Metric Snapshots
|
||||
|
||||
**User Story:** As a quantitative analyst, I want aggregate model metrics stored as time-series snapshots, so that I can track whether model quality is improving or degrading over time.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Metrics_Engine SHALL periodically compute and store model_metric_snapshots containing all aggregate metrics for each combination of lookback window and prediction horizon.
|
||||
2. EACH model_metric_snapshot SHALL contain: prediction count, win rate, directional accuracy, IC, Rank IC, average return, average excess return vs SPY, average excess return vs sector, calibration error (ECE), Brier score, and per-action win rates (buy, sell, hold).
|
||||
3. THE Metrics_Engine SHALL store model_metric_snapshots in a new `model_metric_snapshots` database table with a UUID primary key and indexed columns for generated_at, lookback_window, and horizon.
|
||||
4. THE Metrics_Engine SHALL compute snapshots for lookback windows of 7 days, 30 days, 90 days, and all-time.
|
||||
5. THE Metrics_Engine SHALL store a JSONB metadata field in each snapshot for extensibility, containing any additional computed metrics not captured in dedicated columns.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 11: Safety Gate for Live Trading
|
||||
|
||||
**User Story:** As a platform operator, I want live trading automatically disabled when model quality metrics fall below minimum thresholds, so that the system does not risk real capital on a poorly performing model.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Quality_Gate SHALL evaluate the following minimum thresholds for live trading eligibility: minimum prediction count of 100, minimum IC of 0.03, minimum win rate of 0.53, maximum ECE of 0.15, and minimum excess return vs SPY of 0.0.
|
||||
2. WHEN any threshold is not met, THE Quality_Gate SHALL force all recommendations to paper mode, overriding any live_eligible mode assignments.
|
||||
3. THE Quality_Gate SHALL evaluate gate status at the start of each aggregation cycle by reading the most recent model_metric_snapshot.
|
||||
4. THE Quality_Gate SHALL log the gate evaluation result including which thresholds passed and which failed, with their actual values.
|
||||
5. THE Quality_Gate SHALL store the gate evaluation result in the `risk_configs` table under a `model_quality_gate` key, making it available to the recommendation engine and dashboard.
|
||||
6. IF the model_metric_snapshots table is empty or the most recent snapshot is older than 24 hours, THEN THE Quality_Gate SHALL default to paper-only mode (fail-safe behavior).
|
||||
7. THE Quality_Gate SHALL support configurable thresholds via the `risk_configs` table, with the default values specified in acceptance criterion 1 used when no override is configured.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 12: Model Performance Dashboard Upgrade
|
||||
|
||||
**User Story:** As a platform operator, I want a comprehensive model performance dashboard showing prediction accuracy, calibration, attribution, and gate status, so that I can monitor model quality and make informed decisions about live trading.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Dashboard_API SHALL expose a `/api/validation/summary` endpoint returning the latest model metric snapshot with summary cards for: prediction count, win rate, directional accuracy, IC, Rank IC, Brier score, calibration error, average excess return vs SPY, average excess return vs sector, and live trading gate status.
|
||||
2. THE Dashboard_API SHALL expose a `/api/validation/calibration` endpoint returning the calibration table with confidence buckets, average confidence, observed win rate, prediction count, and miscalibration flag for each bucket.
|
||||
3. THE Dashboard_API SHALL expose a `/api/validation/ic-by-horizon` endpoint returning IC and Rank IC values for each prediction horizon.
|
||||
4. THE Dashboard_API SHALL expose a `/api/validation/attribution/sources` endpoint returning per-source performance metrics including win rate, IC, average return, and duplicate rate.
|
||||
5. THE Dashboard_API SHALL expose a `/api/validation/attribution/catalysts` endpoint returning per-catalyst-type performance metrics.
|
||||
6. THE Dashboard_API SHALL expose a `/api/validation/attribution/layers` endpoint returning per-signal-layer (company, macro, competitive) performance metrics.
|
||||
7. THE Dashboard_API SHALL expose a `/api/validation/gate-status` endpoint returning the current quality gate evaluation with pass/fail status for each threshold.
|
||||
8. THE frontend OpsModel page SHALL be upgraded to display the model validation summary cards, calibration table, IC-by-horizon table, source performance table, catalyst truth table, layer attribution table, and gate status indicator.
|
||||
9. THE frontend SHALL highlight miscalibrated confidence buckets where `|avg_confidence - observed_win_rate| > 0.15` with a visual warning indicator.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 13: Recommendation Display Enhancements
|
||||
|
||||
**User Story:** As a platform operator, I want each recommendation to display its validation context including calibrated confidence, historical win rate, and evidence quality indicators, so that I can assess the reliability of individual predictions.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN displaying a recommendation, THE frontend SHALL show the original confidence alongside the calibrated confidence (based on the historical win rate for that confidence bucket).
|
||||
2. WHEN displaying a recommendation, THE frontend SHALL show the historical win rate for predictions with similar confidence levels.
|
||||
3. WHEN displaying a recommendation, THE frontend SHALL show the evidence count, unique evidence count, and duplicate evidence count.
|
||||
4. WHEN displaying a recommendation, THE frontend SHALL show a source reliability indicator based on the Bayesian-shrunk reliability score of the primary contributing sources.
|
||||
5. WHEN displaying a recommendation, THE frontend SHALL show the live eligibility status with the reason (gate passed, or which threshold failed).
|
||||
6. WHEN the duplicate evidence count exceeds 20% of the total evidence count, THE frontend SHALL display a warning badge indicating potential evidence inflation.
|
||||
7. WHEN the primary contributing source has a reliability score below 0.4, THE frontend SHALL display a warning badge indicating unknown or low source reliability.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 14: SQL Explorer Views
|
||||
|
||||
**User Story:** As a quantitative analyst, I want pre-built SQL views joining predictions with outcomes and evidence with performance, so that I can run ad-hoc analysis in the SQL Explorer without writing complex joins.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE database migration SHALL create a view `v_prediction_performance` that joins prediction_snapshots with prediction_outcomes on prediction_id, providing a single flat table with prediction inputs and realized outcomes.
|
||||
2. THE database migration SHALL create a view `v_source_performance` that joins signal_evidence_links with prediction_outcomes (via prediction_id), providing per-evidence-link outcome data for source attribution analysis.
|
||||
3. THE v_prediction_performance view SHALL include columns for ticker, direction, action, confidence, strength, price_at_prediction, future_return, excess_return_vs_spy, direction_correct, profitable, horizon, generated_at, and evaluated_at.
|
||||
4. THE v_source_performance view SHALL include columns for source, source_type, catalyst_type, sentiment, weight, contribution_score, is_duplicate, direction_correct, future_return, and excess_return_vs_spy.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 15: Backtest Replay Integration
|
||||
|
||||
**User Story:** As a quantitative analyst, I want to replay historical data through the prediction snapshot and outcome evaluation pipeline, so that I can assess model quality on historical data without future data leakage.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Backtest_Replay service SHALL support a validation mode that generates prediction snapshots and evaluates outcomes using only data available at each historical point in time.
|
||||
2. WHEN running in validation mode, THE Backtest_Replay service SHALL process historical recommendations chronologically, creating prediction snapshots with the market prices that were available at each recommendation's generation time.
|
||||
3. WHEN running in validation mode, THE Backtest_Replay service SHALL evaluate prediction outcomes using market prices from the appropriate future horizon relative to each prediction's generation time.
|
||||
4. THE Backtest_Replay service SHALL prevent future data leakage by ensuring that no market data with a timestamp after the prediction generation time is used during snapshot creation.
|
||||
5. WHEN a backtest validation run completes, THE Backtest_Replay service SHALL trigger a model metrics computation over the backtest period, storing the results as model_metric_snapshots tagged with the backtest_id.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 16: Database Schema
|
||||
|
||||
**User Story:** As a developer, I want the new database tables created via a migration script following the existing migration conventions, so that the schema changes are applied consistently across all environments.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE database migration SHALL create the `prediction_snapshots` table with columns: id (UUID PK), generated_at (TIMESTAMPTZ), ticker (VARCHAR), window (VARCHAR), horizon (VARCHAR), direction (VARCHAR), action (VARCHAR), mode (VARCHAR), strength (FLOAT), confidence (FLOAT), contradiction (FLOAT), p_bull (FLOAT), p_bear (FLOAT), score_company (FLOAT), score_macro (FLOAT), score_competitive (FLOAT), evidence_count (INTEGER), unique_source_count (INTEGER), duplicate_evidence_count (INTEGER), price_at_prediction (FLOAT), spy_price_at_prediction (FLOAT), sector_etf_price_at_prediction (FLOAT), metadata (JSONB), created_at (TIMESTAMPTZ).
|
||||
2. THE database migration SHALL create the `prediction_outcomes` table with columns: id (UUID PK), prediction_id (UUID FK to prediction_snapshots), evaluated_at (TIMESTAMPTZ), horizon (VARCHAR), future_price (FLOAT), future_return (FLOAT), spy_future_price (FLOAT), spy_return (FLOAT), sector_etf_future_price (FLOAT), sector_etf_return (FLOAT), excess_return_vs_spy (FLOAT), excess_return_vs_sector (FLOAT), direction_correct (BOOLEAN), profitable (BOOLEAN), metadata (JSONB), created_at (TIMESTAMPTZ).
|
||||
3. THE database migration SHALL create the `signal_evidence_links` table with columns: id (UUID PK), prediction_id (UUID FK to prediction_snapshots), document_id (VARCHAR), signal_id (VARCHAR), ticker (VARCHAR), source (VARCHAR), source_type (VARCHAR), catalyst_type (VARCHAR), sentiment (VARCHAR), impact (FLOAT), extraction_confidence (FLOAT), weight (FLOAT), is_duplicate (BOOLEAN), canonical_evidence_key (VARCHAR), contribution_score (FLOAT), metadata (JSONB), created_at (TIMESTAMPTZ).
|
||||
4. THE database migration SHALL create the `model_metric_snapshots` table with columns: id (UUID PK), generated_at (TIMESTAMPTZ), lookback_window (VARCHAR), horizon (VARCHAR), prediction_count (INTEGER), win_rate (FLOAT), directional_accuracy (FLOAT), information_coefficient (FLOAT), rank_information_coefficient (FLOAT), avg_return (FLOAT), avg_excess_return_vs_spy (FLOAT), avg_excess_return_vs_sector (FLOAT), calibration_error (FLOAT), brier_score (FLOAT), buy_win_rate (FLOAT), sell_win_rate (FLOAT), hold_win_rate (FLOAT), metadata (JSONB), created_at (TIMESTAMPTZ).
|
||||
5. THE database migration SHALL create appropriate indexes on prediction_snapshots (ticker, generated_at, horizon), prediction_outcomes (prediction_id, horizon), signal_evidence_links (prediction_id, document_id, ticker), and model_metric_snapshots (generated_at, lookback_window, horizon).
|
||||
6. THE database migration SHALL be numbered as `035_model_validation.sql`, following the existing migration numbering convention.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 17: Property-Based Testing for Validation Metrics
|
||||
|
||||
**User Story:** As a developer, I want property-based tests validating the mathematical correctness of all validation metric computations, so that edge cases and numerical stability issues are caught before deployment.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE test suite SHALL include a property-based test for calibration error verifying that ECE is in [0.0, 1.0] for all valid distributions of predictions across confidence buckets, and that ECE is 0.0 when every bucket's observed win rate exactly matches its average confidence (round-trip calibration property).
|
||||
2. THE test suite SHALL include a property-based test for Brier score verifying that the score is in [0.0, 1.0] for all valid probability-outcome pairs, and that the score is 0.0 when all predictions are perfectly correct with probability 1.0.
|
||||
3. THE test suite SHALL include a property-based test for information coefficient verifying that IC is in [-1.0, 1.0] for all valid score-return pairs, and that IC is 1.0 when scores and returns are perfectly positively correlated.
|
||||
4. THE test suite SHALL include a property-based test for the canonical evidence key verifying that the key is deterministic (same inputs always produce the same key) and that normalization is idempotent (normalizing an already-normalized input produces the same key).
|
||||
5. THE test suite SHALL include a property-based test for source reliability Bayesian shrinkage verifying that reliability is always in [0.0, 1.0], that reliability approaches 0.5 as sample count approaches 0, and that reliability approaches the observed win rate as sample count approaches infinity.
|
||||
6. THE test suite SHALL include a property-based test for the quality gate verifying that the gate result is deterministic for the same metric inputs, and that relaxing any single threshold (making it easier to pass) never causes a previously passing gate to fail (monotonicity property).
|
||||
7. THE test suite SHALL include a property-based test for contribution score computation verifying that all contribution scores for a single prediction sum to 1.0 (within floating-point tolerance) and that each individual score is in [0.0, 1.0].
|
||||
@@ -0,0 +1,260 @@
|
||||
# Implementation Plan: Model Validation, Calibration, and Signal Quality
|
||||
|
||||
## Overview
|
||||
|
||||
Add a closed-loop model validation layer to Stonks Oracle: prediction snapshot capture, outcome evaluation, calibration/IC metrics, source/catalyst/layer attribution, Bayesian source reliability, a quality gate for live trading, 7 new API endpoints, an upgraded OpsModel dashboard, and backtest replay integration. Implementation follows the four-phase priority order from the spec, with each phase building on the previous one.
|
||||
|
||||
## Tasks
|
||||
|
||||
- [x] 1. Database migration 035 — schema foundation
|
||||
- [x] 1.1 Create `infra/migrations/035_model_validation.sql` with all tables, indexes, and views
|
||||
- Create `prediction_snapshots` table with all columns from design (id UUID PK, generated_at, ticker, window, horizon, direction, action, mode, strength, confidence, contradiction, p_bull, p_bear, score_company, score_macro, score_competitive, evidence_count, unique_source_count, duplicate_evidence_count, price_at_prediction, spy_price_at_prediction, sector_etf_price_at_prediction, metadata JSONB, created_at)
|
||||
- Create `prediction_outcomes` table with FK to prediction_snapshots (id UUID PK, prediction_id, evaluated_at, horizon, future_price, future_return, spy_future_price, spy_return, sector_etf_future_price, sector_etf_return, excess_return_vs_spy, excess_return_vs_sector, direction_correct, profitable, metadata JSONB, created_at)
|
||||
- Create `signal_evidence_links` table with FK to prediction_snapshots (id UUID PK, prediction_id, document_id, signal_id, ticker, source, source_type, catalyst_type, sentiment, impact, extraction_confidence, weight, is_duplicate, canonical_evidence_key, contribution_score, metadata JSONB, created_at)
|
||||
- Create `model_metric_snapshots` table (id UUID PK, generated_at, lookback_window, horizon, prediction_count, win_rate, directional_accuracy, information_coefficient, rank_information_coefficient, avg_return, avg_excess_return_vs_spy, avg_excess_return_vs_sector, calibration_error, brier_score, buy_win_rate, sell_win_rate, hold_win_rate, metadata JSONB, created_at)
|
||||
- Create indexes on prediction_snapshots (ticker, generated_at, horizon), prediction_outcomes (prediction_id, horizon, evaluated_at), signal_evidence_links (prediction_id, document_id, ticker), model_metric_snapshots (generated_at, lookback_window, horizon)
|
||||
- Create `v_prediction_performance` view joining prediction_snapshots with prediction_outcomes
|
||||
- Create `v_source_performance` view joining signal_evidence_links with prediction_snapshots and prediction_outcomes
|
||||
- _Requirements: 16.1, 16.2, 16.3, 16.4, 16.5, 16.6, 14.1, 14.2, 14.3, 14.4_
|
||||
|
||||
- [x] 2. Phase 1 — Prediction capture, outcome evaluation, core metrics, and dashboard API
|
||||
- [x] 2.1 Implement Prediction Snapshot Writer (`services/validation/prediction_snapshot.py`)
|
||||
- Create `services/validation/__init__.py`
|
||||
- Define `SECTOR_ETF_MAP`, `EVALUATION_HORIZONS`, `MAX_SINGLE_DOCUMENT_WEIGHT` constants
|
||||
- Implement `PredictionSnapshot` and `SignalEvidenceLink` dataclasses
|
||||
- Implement `compute_canonical_evidence_key(title, url)` — SHA256 of normalized title + normalized URL (lowercase, strip whitespace for title; lowercase, strip query params for URL)
|
||||
- Implement `fetch_latest_close_price(pool, ticker)` — query most recent close from market_snapshots
|
||||
- Implement `create_prediction_snapshot(pool, recommendation, trend_summary, evidence_signals, evidence_docs)` — fetch prices (ticker, SPY, sector ETF), compute canonical keys, detect duplicates, clamp weights to MAX_SINGLE_DOCUMENT_WEIGHT, compute contribution scores (one-vote-per-canonical-key), persist snapshot + evidence links in a transaction
|
||||
- Implement `compute_contribution_scores(weights)` — each score = weight_i / sum(weights), sums to 1.0
|
||||
- Handle NULL prices gracefully (log warning, store NULL, don't fail)
|
||||
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 3.1, 3.2, 3.3, 3.4_
|
||||
|
||||
- [x] 2.2 Write property test for canonical evidence key determinism and idempotence
|
||||
- **Property 4: Canonical Evidence Key Determinism and Normalization Idempotence**
|
||||
- Test that same (title, url) always produces same key
|
||||
- Test that normalizing already-normalized input produces same key
|
||||
- **Validates: Requirements 2.3, 17.4**
|
||||
|
||||
- [x] 2.3 Write property test for contribution score sum-to-one and range
|
||||
- **Property 7: Contribution Score Sum-to-One and Range**
|
||||
- Test that all scores in [0.0, 1.0] and sum to 1.0 (within 1e-9 tolerance)
|
||||
- Test that empty input returns empty list
|
||||
- **Validates: Requirements 2.5, 17.7**
|
||||
|
||||
- [x] 2.4 Implement Outcome Evaluator (`services/validation/outcome_evaluator.py`)
|
||||
- Define `PredictionOutcome` dataclass and `HORIZON_DURATIONS` mapping
|
||||
- Implement `evaluate_matured_predictions(pool)` — find snapshots where horizon elapsed and outcome not recorded, evaluate each
|
||||
- Implement `evaluate_single_prediction(pool, snapshot, horizon)` — fetch future price at horizon endpoint, compute future_return, SPY return, sector ETF return, excess returns, direction_correct, profitable; return None if future price unavailable
|
||||
- Evaluate across all 5 horizons: 1h, 6h, 1d, 7d, 30d
|
||||
- Skip horizons where future price is unavailable (retry next run)
|
||||
- Store results in prediction_outcomes table
|
||||
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 4.10_
|
||||
|
||||
- [x] 2.5 Implement Metrics Engine (`services/validation/metrics.py`)
|
||||
- Define `CONFIDENCE_BUCKETS`, `LOOKBACK_WINDOWS` constants
|
||||
- Define `CalibrationBucket` and `ModelMetricSnapshot` dataclasses
|
||||
- Implement `compute_calibration_error(confidences, outcomes)` — group into 5 confidence buckets, compute ECE as weighted average of |avg_conf - win_rate|, flag miscalibrated buckets (|diff| > 0.15)
|
||||
- Implement `compute_brier_score(p_bulls, outcomes)` — mean((p_bull - outcome)^2)
|
||||
- Implement `compute_information_coefficient(scores, returns)` — Pearson correlation, return None when < 30 data points
|
||||
- Implement `compute_rank_information_coefficient(scores, returns)` — Spearman rank correlation, return None when < 30 data points
|
||||
- Implement `compute_contribution_scores(weights)` — weight_i / sum(weights), sums to 1.0
|
||||
- Implement benchmark metrics: average excess return vs SPY, vs sector ETF, hit rate improvement
|
||||
- Implement `compute_and_store_metric_snapshots(pool)` — compute for all lookback/horizon combinations (4 lookbacks × 5 horizons), persist to model_metric_snapshots
|
||||
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 6.1, 6.2, 6.3, 6.4, 6.5, 9.1, 9.2, 9.3, 9.4, 10.1, 10.2, 10.3, 10.4, 10.5_
|
||||
|
||||
- [x] 2.6 Write property test for ECE range and round-trip
|
||||
- **Property 1: Calibration Error Range and Round-Trip**
|
||||
- Test ECE in [0.0, 1.0] for all valid distributions
|
||||
- Test ECE = 0.0 when every bucket's win rate matches avg confidence
|
||||
- **Validates: Requirements 5.1, 5.3, 17.1**
|
||||
|
||||
- [x] 2.7 Write property test for Brier score range and perfect prediction
|
||||
- **Property 2: Brier Score Range and Perfect Prediction**
|
||||
- Test Brier in [0.0, 1.0] for all valid (p_bull, outcome) pairs
|
||||
- Test Brier = 0.0 when all predictions perfectly correct
|
||||
- **Validates: Requirements 5.4, 17.2**
|
||||
|
||||
- [x] 2.8 Write property test for IC range and perfect correlation
|
||||
- **Property 3: Information Coefficient Range and Perfect Correlation**
|
||||
- Test IC in [-1.0, 1.0] for all valid (score, return) pairs with ≥30 elements
|
||||
- Test IC = 1.0 for perfectly positively correlated data
|
||||
- **Validates: Requirements 6.1, 6.2, 17.3**
|
||||
|
||||
- [x] 2.9 Implement Dashboard API endpoints in `services/api/app.py`
|
||||
- Add `/api/validation/summary` GET — return latest model_metric_snapshot + gate status
|
||||
- Add `/api/validation/calibration` GET — return calibration table with buckets
|
||||
- Add `/api/validation/ic-by-horizon` GET — return IC and Rank IC per horizon
|
||||
- Add `/api/validation/gate-status` GET — return quality gate evaluation detail
|
||||
- All endpoints accept optional `lookback` (default "30d") and `horizon` (default "7d") query params
|
||||
- _Requirements: 12.1, 12.2, 12.3, 12.7_
|
||||
|
||||
- [x] 2.10 Add frontend validation API hooks in `frontend/src/api/hooks.ts`
|
||||
- Add `useValidationSummary(lookback?, horizon?)` hook for `/api/validation/summary`
|
||||
- Add `useValidationCalibration(lookback?, horizon?)` hook for `/api/validation/calibration`
|
||||
- Add `useValidationICByHorizon(lookback?)` hook for `/api/validation/ic-by-horizon`
|
||||
- Add `useValidationGateStatus()` hook for `/api/validation/gate-status`
|
||||
- _Requirements: 12.1, 12.2, 12.3, 12.7_
|
||||
|
||||
- [x] 2.11 Upgrade OpsModel page (`frontend/src/pages/OpsModel.tsx`) — Phase 1 dashboard
|
||||
- Add tabbed layout: existing "Extraction Performance" tab + new "Model Validation" tab
|
||||
- Add summary cards: prediction count, win rate, directional accuracy, IC, Rank IC, Brier score, ECE, avg excess return vs SPY, gate status
|
||||
- Add calibration table with confidence buckets, avg confidence, observed win rate, count, miscalibration flag
|
||||
- Highlight miscalibrated buckets (|avg_confidence - observed_win_rate| > 0.15) with warning indicator
|
||||
- Add IC-by-horizon table showing IC and Rank IC for each horizon
|
||||
- Add gate status indicator (pass/fail with threshold details)
|
||||
- _Requirements: 12.1, 12.2, 12.3, 12.7, 12.8, 12.9_
|
||||
|
||||
- [x] 3. Checkpoint — Phase 1 verification
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 4. Phase 2 — Attribution engine and source/catalyst truth tables
|
||||
- [x] 4.1 Implement Attribution Engine (`services/validation/attribution.py`)
|
||||
- Define `SourceAttribution`, `CatalystAttribution`, `LayerAttribution` dataclasses
|
||||
- Implement `compute_source_attribution(pool, lookback_days, horizon)` — join signal_evidence_links with prediction_outcomes, group by source; compute prediction count, avg weight, avg contribution score, win rate, avg future return, avg excess return vs SPY, IC, duplicate rate
|
||||
- Implement `compute_catalyst_attribution(pool, lookback_days, horizon)` — same metrics grouped by catalyst_type
|
||||
- Implement `compute_layer_attribution(pool, lookback_days, horizon)` — compute per-layer (company, macro, competitive) avg contribution %, dominant win rate (layer > 30% contribution), dominant IC
|
||||
- _Requirements: 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7_
|
||||
|
||||
- [x] 4.2 Implement Calibration Engine (`services/validation/calibration.py`)
|
||||
- Implement `compute_source_reliability(observed_win_rate, sample_count, prior_strength=30)` — Bayesian shrinkage: `0.5 + (n / (n + 30)) * (observed_win_rate - 0.5)`; return 0.5 when n=0
|
||||
- Implement `compute_adjusted_evidence_weight(base_weight, reliability)` — `base_weight * (0.5 + reliability)`, clamped to [0.1, 2.0]
|
||||
- Implement `update_source_reliabilities(pool)` — recompute from latest outcomes, update source_accuracy table
|
||||
- _Requirements: 8.1, 8.2, 8.3, 8.4, 8.5_
|
||||
|
||||
- [x] 4.3 Write property test for source reliability Bayesian shrinkage bounds and convergence
|
||||
- **Property 5: Source Reliability Bayesian Shrinkage Bounds and Convergence**
|
||||
- Test reliability in [0.0, 1.0] for all valid inputs
|
||||
- Test reliability = 0.5 when sample_count = 0
|
||||
- Test reliability approaches observed_win_rate as sample_count → ∞
|
||||
- **Validates: Requirements 8.1, 8.2, 17.5**
|
||||
|
||||
- [x] 4.4 Add attribution API endpoints in `services/api/app.py`
|
||||
- Add `/api/validation/attribution/sources` GET — return per-source performance metrics
|
||||
- Add `/api/validation/attribution/catalysts` GET — return per-catalyst performance metrics
|
||||
- Add `/api/validation/attribution/layers` GET — return per-layer performance metrics
|
||||
- All endpoints accept optional `lookback` (default "30d") and `horizon` (default "7d") query params
|
||||
- _Requirements: 12.4, 12.5, 12.6_
|
||||
|
||||
- [x] 4.5 Add frontend attribution hooks in `frontend/src/api/hooks.ts`
|
||||
- Add `useValidationAttributionSources(lookback?, horizon?)` hook
|
||||
- Add `useValidationAttributionCatalysts(lookback?, horizon?)` hook
|
||||
- Add `useValidationAttributionLayers(lookback?, horizon?)` hook
|
||||
- _Requirements: 12.4, 12.5, 12.6_
|
||||
|
||||
- [x] 4.6 Extend OpsModel page with attribution tables
|
||||
- Add source performance table (source, win rate, IC, avg return, duplicate rate)
|
||||
- Add catalyst truth table (catalyst type, win rate, avg return, IC)
|
||||
- Add layer attribution table (company/macro/competitive contribution %, dominant win rate, IC)
|
||||
- _Requirements: 12.4, 12.5, 12.6, 12.8_
|
||||
|
||||
- [x] 5. Checkpoint — Phase 2 verification
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 6. Phase 3 — Quality gate, recommendation enhancements, and pipeline wiring
|
||||
- [x] 6.1 Implement Quality Gate (`services/trading/model_quality_gate.py`)
|
||||
- Define `QualityGateConfig` dataclass with default thresholds (min_prediction_count=100, min_ic=0.03, min_win_rate=0.53, max_ece=0.15, min_excess_return_vs_spy=0.0, max_snapshot_age_hours=24)
|
||||
- Define `GateThresholdResult` and `QualityGateResult` dataclasses
|
||||
- Implement `evaluate_quality_gate(pool, config)` — read most recent model_metric_snapshot (30d lookback, 7d horizon), evaluate each threshold, store result in risk_configs under 'model_quality_gate' key
|
||||
- Implement `load_gate_config_from_db(pool)` — load thresholds from risk_configs with defaults
|
||||
- Default to paper-only mode when no snapshots exist or snapshot is stale (>24h)
|
||||
- Log gate evaluation result with threshold pass/fail details
|
||||
- _Requirements: 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7_
|
||||
|
||||
- [x] 6.2 Write property test for quality gate determinism and threshold monotonicity
|
||||
- **Property 6: Quality Gate Determinism and Threshold Monotonicity**
|
||||
- Test same inputs always produce same pass/fail result
|
||||
- Test relaxing any threshold never causes a previously passing gate to fail
|
||||
- **Validates: Requirements 11.1, 17.6**
|
||||
|
||||
- [x] 6.3 Wire Quality Gate into aggregation cycle (`services/aggregation/worker.py`)
|
||||
- Call `evaluate_quality_gate` at the start of each aggregation cycle
|
||||
- When gate fails, force all recommendations to paper mode
|
||||
- Log gate status at cycle start
|
||||
- _Requirements: 11.2, 11.3_
|
||||
|
||||
- [x] 6.4 Wire Prediction Snapshot Writer into recommendation engine
|
||||
- After recommendation is generated in `services/recommendation/eligibility.py` or the calling code, call `create_prediction_snapshot` to capture the prediction state
|
||||
- Pass recommendation, trend_summary, evidence signals, and evidence docs
|
||||
- Handle snapshot creation failure gracefully (log error, don't block recommendation)
|
||||
- _Requirements: 1.1, 1.6_
|
||||
|
||||
- [x] 6.5 Enhance recommendation display on frontend
|
||||
- Update `frontend/src/pages/RecommendationDetail` (or relevant recommendation display component) to show:
|
||||
- Original confidence alongside calibrated confidence (historical win rate for that bucket)
|
||||
- Historical win rate for similar confidence levels
|
||||
- Evidence count, unique evidence count, duplicate evidence count
|
||||
- Source reliability indicator for primary contributing sources
|
||||
- Live eligibility status with reason (gate passed or which threshold failed)
|
||||
- Add warning badge when duplicate evidence count > 20% of total evidence count
|
||||
- Add warning badge when primary source reliability < 0.4
|
||||
- _Requirements: 13.1, 13.2, 13.3, 13.4, 13.5, 13.6, 13.7_
|
||||
|
||||
- [x] 7. Checkpoint — Phase 3 verification
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [x] 8. Phase 4 — Backtest replay integration and unit tests
|
||||
- [x] 8.1 Add validation mode to BacktestReplay (`services/trading/backtest_replay.py`)
|
||||
- Add `validation_mode: bool = False` parameter to `BacktestReplay.run()`
|
||||
- When validation_mode=True, create prediction snapshots for each historical recommendation using only data available at that point in time
|
||||
- Evaluate prediction outcomes using market prices from the appropriate future horizon
|
||||
- Prevent future data leakage: no market data after prediction generation time used during snapshot creation
|
||||
- After backtest completes, trigger model metrics computation over the backtest period, tag snapshots with backtest_id
|
||||
- _Requirements: 15.1, 15.2, 15.3, 15.4, 15.5_
|
||||
|
||||
- [x] 8.2 Write unit tests for prediction snapshot writer (`tests/test_model_validation_unit.py`)
|
||||
- Test canonical evidence key: known title/URL → expected SHA256, empty inputs, unicode
|
||||
- Test duplicate detection: 3 docs with 2 sharing a key → 1 marked duplicate
|
||||
- Test contribution scores: [0.5, 0.3, 0.2] → [0.5, 0.3, 0.2], single doc → [1.0]
|
||||
- Test weight clamping: weight 1.5 → clamped to 1.0
|
||||
- _Requirements: 1.1, 2.3, 2.4, 2.5, 3.3_
|
||||
|
||||
- [x] 8.3 Write unit tests for outcome evaluator (`tests/test_model_validation_unit.py`)
|
||||
- Test future return computation: price 100→110 → 0.10, price 100→90 → -0.10
|
||||
- Test direction_correct logic: bullish+positive → true, bullish+negative → false
|
||||
- Test profitable logic: buy+positive → true, sell+negative → true
|
||||
- Test excess return: ticker 10%, SPY 5% → excess 5%
|
||||
- _Requirements: 4.2, 4.5, 4.6, 4.7_
|
||||
|
||||
- [x] 8.4 Write unit tests for metrics engine (`tests/test_model_validation_unit.py`)
|
||||
- Test ECE specific values: perfect calibration → 0.0, all overconfident → positive ECE
|
||||
- Test Brier score: all correct at p=1.0 → 0.0, all wrong at p=1.0 → 1.0
|
||||
- Test IC: perfect correlation → 1.0, anti-correlation → -1.0, < 30 → None
|
||||
- _Requirements: 5.3, 5.4, 6.1, 6.2, 6.5_
|
||||
|
||||
- [x] 8.5 Write unit tests for calibration engine (`tests/test_model_validation_unit.py`)
|
||||
- Test source reliability: n=0 → 0.5, n=1000 with wr=0.8 → ≈0.8, n=30 with wr=0.7 → 0.6
|
||||
- Test adjusted evidence weight: reliability=0.5 → base*1.0, clamping to [0.1, 2.0]
|
||||
- _Requirements: 8.1, 8.2, 8.3_
|
||||
|
||||
- [x] 8.6 Write unit tests for quality gate (`tests/test_model_validation_unit.py`)
|
||||
- Test all thresholds met → pass
|
||||
- Test one threshold failed → fail with reason
|
||||
- Test fail-safe: no snapshots → paper-only, stale snapshot → paper-only
|
||||
- _Requirements: 11.1, 11.6_
|
||||
|
||||
- [x] 8.7 Write frontend tests for validation dashboard (`frontend/src/test/pages.test.tsx`)
|
||||
- Add MSW mock handlers for `/api/validation/summary`, `/api/validation/calibration`, `/api/validation/gate-status`
|
||||
- Test OpsModel page renders validation tab with summary cards
|
||||
- Test calibration table renders buckets with miscalibration warning
|
||||
- Test gate status indicator renders pass/fail
|
||||
- _Requirements: 12.8, 12.9_
|
||||
|
||||
- [x] 9. Final checkpoint — Ensure all tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
## Notes
|
||||
|
||||
- Tasks marked with `*` are optional and can be skipped for faster MVP
|
||||
- Each task references specific requirements for traceability
|
||||
- Checkpoints ensure incremental validation after each phase
|
||||
- Property tests validate the 7 universal correctness properties from the design document
|
||||
- Unit tests validate specific examples, edge cases, and integration points
|
||||
- The design uses Python for backend and TypeScript for frontend — no language selection needed
|
||||
- Migration number is 035 (existing migrations go up to 034)
|
||||
- All new service modules go under `services/validation/` except the quality gate which goes in `services/trading/`
|
||||
- The 7 new API endpoints are added to the existing `services/api/app.py`
|
||||
- Frontend hooks follow existing patterns in `frontend/src/api/hooks.ts`
|
||||
- Phase 1 delivers the core feedback loop (capture → evaluate → measure → display)
|
||||
- Phase 2 adds attribution depth (which sources/catalysts/layers work best)
|
||||
- Phase 3 adds safety (quality gate) and UX (recommendation warnings)
|
||||
- Phase 4 adds historical analysis (backtest validation mode) and comprehensive tests
|
||||
@@ -0,0 +1 @@
|
||||
{"specId": "f5d99301-94ef-4dc2-8ba4-ccefeee7ecba", "workflowType": "requirements-first", "specType": "bugfix"}
|
||||
@@ -0,0 +1,73 @@
|
||||
# Bugfix Requirements Document
|
||||
|
||||
## Introduction
|
||||
|
||||
Multiple operational bugs discovered in the stonks-beta namespace prevent the validation/calibration feedback loop from functioning and degrade ingestion throughput. The core issue is that the outcome evaluation → metrics computation → quality gate pipeline is completely disconnected from the production scheduler, making the platform unable to self-calibrate or validate predictions. Additionally, Polygon API rate limiting causes ~40% request failures per cycle, a broken config query prevents the v3 engine from being toggled, several periodic snapshot tasks are missing from the scheduler, the lake-publisher deployment is idle/redundant, and order rejection reasons are lost.
|
||||
|
||||
## Bug Analysis
|
||||
|
||||
### Current Behavior (Defect)
|
||||
|
||||
1.1 WHEN the scheduler enqueues ingestion jobs for all 50 tickers' news_api and market_api sources simultaneously THEN the system exhausts the Polygon free-tier rate limit (5 req/min) resulting in ~40% of sources receiving HTTP 429 Too Many Requests every cycle
|
||||
|
||||
1.2 WHEN the aggregation worker reads the v3_engine_enabled flag via `_V3_ENGINE_FLAG_QUERY` THEN the system queries non-existent columns `key` and `value` on the `risk_configs` table (actual schema: `name` varchar, `config` JSONB) causing a PostgreSQL error every aggregation cycle
|
||||
|
||||
1.3 WHEN a scheduler cycle completes THEN the system never calls `evaluate_matured_predictions()` because it is not wired into the scheduler's main loop — only imported in `backtest_replay.py`
|
||||
|
||||
1.4 WHEN a scheduler cycle completes THEN the system never calls `compute_and_store_metric_snapshots()` because it is not wired into the scheduler's main loop — only called from backtest replay
|
||||
|
||||
1.5 WHEN the model quality gate evaluates trading eligibility THEN the system always fails with "no model metric snapshot available — defaulting to paper-only" because `model_metric_snapshots` table is permanently empty (consequence of bug 1.4)
|
||||
|
||||
1.6 WHEN the trading engine runs daily THEN the system never captures portfolio state snapshots to the `portfolio_snapshots` table because no periodic scheduler task invokes this capture
|
||||
|
||||
1.7 WHEN the trading engine runs daily THEN the system never captures risk state snapshots to the `daily_risk_snapshots` table because no periodic scheduler task invokes this capture
|
||||
|
||||
1.8 WHEN a prediction snapshot is created while Polygon rate-limiting has prevented the market data fetch THEN the system stores NULL in `price_at_prediction` (affecting 21% of snapshots), degrading downstream outcome evaluation accuracy
|
||||
|
||||
1.9 WHEN the standalone `lake-publisher` deployment polls `stonks:beta:queue:lake_publish` THEN the queue is always empty (0 items) because all lake publishing happens inline in broker-adapter and recommendation services — the deployment consumes zero work and wastes resources
|
||||
|
||||
1.10 WHEN Alpaca returns HTTP 401 for an order submission THEN the system sets order status to "rejected" but leaves the `rejection_reason` column NULL, capturing the error message only in the `decision_trace` JSONB field
|
||||
|
||||
### Expected Behavior (Correct)
|
||||
|
||||
2.1 WHEN the scheduler enqueues ingestion jobs for Polygon-backed sources (news_api, market_api) THEN the system SHALL pace/stagger requests across the polling interval to stay within the Polygon rate limit, achieving near-zero 429 responses per cycle
|
||||
|
||||
2.2 WHEN the aggregation worker reads the v3_engine_enabled flag THEN the system SHALL query `SELECT config FROM risk_configs WHERE name = 'v3_engine_enabled'` and parse the JSONB value to determine the boolean toggle state
|
||||
|
||||
2.3 WHEN a scheduler cycle completes and sufficient time has elapsed since the last evaluation THEN the system SHALL call `evaluate_matured_predictions()` to evaluate prediction snapshots whose horizon has elapsed, populating the `prediction_outcomes` table
|
||||
|
||||
2.4 WHEN a scheduler cycle completes and sufficient time has elapsed since the last computation THEN the system SHALL call `compute_and_store_metric_snapshots()` to compute aggregate model metrics across all lookback/horizon combinations, populating `model_metric_snapshots`
|
||||
|
||||
2.5 WHEN the model quality gate evaluates trading eligibility THEN the system SHALL have recent metric snapshots available and evaluate thresholds against actual model performance data
|
||||
|
||||
2.6 WHEN market hours close (or on a daily schedule) THEN the system SHALL capture and persist the current portfolio state to `portfolio_snapshots` including value, returns, positions, and risk metrics
|
||||
|
||||
2.7 WHEN market hours close (or on a daily schedule) THEN the system SHALL capture and persist the current risk state to `daily_risk_snapshots` including portfolio value, daily P&L, trade count, and sector positions
|
||||
|
||||
2.8 WHEN a prediction snapshot is created and market price is unavailable due to rate limiting THEN the system SHALL retry the price fetch or defer the snapshot until price data is available, reducing NULL `price_at_prediction` occurrences to near zero
|
||||
|
||||
2.9 WHEN the lake-publisher deployment architecture is reviewed THEN the system SHALL either route lake publish jobs through the Redis queue to the standalone deployment, or remove the redundant deployment — eliminating the idle pod
|
||||
|
||||
2.10 WHEN Alpaca returns an HTTP error (401, 403, or any rejection) for an order submission THEN the system SHALL populate the `rejection_reason` column with the HTTP error message/status in addition to recording it in `decision_trace`
|
||||
|
||||
### Unchanged Behavior (Regression Prevention)
|
||||
|
||||
3.1 WHEN sources with valid rate-limit headroom are enqueued THEN the system SHALL CONTINUE TO enqueue and process them without artificial delay
|
||||
|
||||
3.2 WHEN risk_configs is queried for other configuration keys (e.g., `model_quality_gate_config`, `macro_enabled`) THEN the system SHALL CONTINUE TO read them correctly using the existing `name`/`config` column pattern
|
||||
|
||||
3.3 WHEN the backtest replay module calls `evaluate_matured_predictions()` and `compute_and_store_metric_snapshots()` THEN the system SHALL CONTINUE TO execute them as part of backtest validation
|
||||
|
||||
3.4 WHEN prediction snapshots are created with available market prices THEN the system SHALL CONTINUE TO store the correct `price_at_prediction` value immediately
|
||||
|
||||
3.5 WHEN the existing inline lake publishing in broker-adapter and recommendation services writes facts THEN the system SHALL CONTINUE TO produce correct Parquet partitions in MinIO
|
||||
|
||||
3.6 WHEN orders succeed (HTTP 200 from Alpaca) THEN the system SHALL CONTINUE TO process them normally without modifying the `rejection_reason` column
|
||||
|
||||
3.7 WHEN the scheduler runs ingestion, extraction, aggregation, recommendation, and trading tasks THEN the system SHALL CONTINUE TO execute them on the existing cadence without disruption
|
||||
|
||||
3.8 WHEN the trading engine makes decisions and submits orders THEN the system SHALL CONTINUE TO record full decision context in `decision_trace` JSONB as before
|
||||
|
||||
3.9 WHEN the model quality gate passes (once metrics are populated) THEN the system SHALL CONTINUE TO allow promotion to live trading mode per existing threshold logic
|
||||
|
||||
3.10 WHEN the reporting collector fetches portfolio_snapshots and daily_risk_snapshots for report generation THEN the system SHALL CONTINUE TO query and render them using the existing schema
|
||||
@@ -0,0 +1,396 @@
|
||||
# Technical Design: ops-pipeline-fixes
|
||||
|
||||
## Overview
|
||||
|
||||
This design addresses 10 operational bugs that prevent the validation/calibration feedback loop from functioning and degrade ingestion throughput in the `stonks-beta` namespace. The fixes span the scheduler (rate limiting + periodic tasks), aggregation worker (config query), broker service (rejection reason), prediction snapshot (price fallback), and Helm chart (dead pod removal). All changes are localized with graceful fallbacks and no schema migrations required.
|
||||
|
||||
## Bug Details
|
||||
|
||||
Multiple operational bugs in the `stonks-beta` namespace prevent the validation/calibration feedback loop from functioning and degrade ingestion throughput. The core pipeline (ingestion → extraction → aggregation → recommendation → trading) flows end-to-end, but:
|
||||
- The outcome evaluation → metrics computation → quality gate feedback loop is completely disconnected
|
||||
- Polygon API rate limiting causes ~40% ingestion failures per cycle
|
||||
- A broken config query prevents the v3 engine toggle from working
|
||||
- Portfolio/risk snapshots are never captured
|
||||
- Order rejection reasons are lost
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph "Scheduler (services/scheduler/app.py)"
|
||||
A[schedule_cycle] -->|paced enqueue| B[Ingestion Queue]
|
||||
C[validation_cycle] -->|hourly| D[evaluate_matured_predictions]
|
||||
C -->|after outcomes| E[compute_and_store_metric_snapshots]
|
||||
F[snapshot_cycle] -->|daily 16:30 ET| G[capture_portfolio_snapshot]
|
||||
F -->|daily 16:30 ET| H[capture_risk_snapshot]
|
||||
end
|
||||
|
||||
subgraph "Aggregation (services/aggregation/worker.py)"
|
||||
I[_read_v3_flag] -->|fixed query| J[risk_configs.config JSONB]
|
||||
end
|
||||
|
||||
subgraph "Broker (services/adapters/broker_service.py)"
|
||||
K[persist_order] -->|rejected status| L[orders.rejection_reason]
|
||||
end
|
||||
|
||||
D --> O[prediction_outcomes]
|
||||
E --> P[model_metric_snapshots]
|
||||
P --> Q[Quality Gate]
|
||||
```
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
2.1 The scheduler SHALL pace Polygon API requests within the free-tier limit (~5 req/min), achieving near-zero 429 responses per cycle.
|
||||
|
||||
2.2 The aggregation worker SHALL read `v3_engine_enabled` from the `risk_configs` JSONB `config` column (not non-existent `key`/`value` columns).
|
||||
|
||||
2.3 The scheduler SHALL call `evaluate_matured_predictions()` hourly to populate `prediction_outcomes`.
|
||||
|
||||
2.4 The scheduler SHALL call `compute_and_store_metric_snapshots()` after outcome evaluation to populate `model_metric_snapshots`.
|
||||
|
||||
2.5 The quality gate SHALL have recent metric data available once the validation cycle runs.
|
||||
|
||||
2.6 The scheduler SHALL capture daily portfolio snapshots to `portfolio_snapshots` after market close.
|
||||
|
||||
2.7 The scheduler SHALL capture daily risk snapshots to `daily_risk_snapshots` after market close.
|
||||
|
||||
2.8 Prediction snapshots SHALL fall back to positions table prices when market_snapshots data is unavailable.
|
||||
|
||||
2.9 The lake-publisher deployment SHALL be scaled to 0 (idle pod, wasted resources).
|
||||
|
||||
2.10 The broker service SHALL populate `rejection_reason` on orders when broker or risk engine rejects.
|
||||
|
||||
## Hypothesized Root Cause
|
||||
|
||||
### Bug 1.1 — Polygon Rate Limiting
|
||||
`POLYGON_GLOBAL_RATE_LIMIT = 45` in `services/scheduler/app.py` is set for a paid Polygon plan but the deployed instance uses the free tier (5 req/min). All 50+ sources are attempted per cycle, exhausting the limit instantly.
|
||||
|
||||
### Bug 1.2 — v3_engine_enabled Config Read
|
||||
`_V3_ENGINE_FLAG_QUERY` in `services/aggregation/worker.py` reads `SELECT value FROM risk_configs WHERE key = 'v3_engine_enabled'`. The actual table has columns `name` (varchar) and `config` (JSONB) — no `key` or `value` column exists.
|
||||
|
||||
### Bug 1.3 & 1.4 — Outcome Evaluator & Metrics Never Scheduled
|
||||
`evaluate_matured_predictions()` and `compute_and_store_metric_snapshots()` exist in `services/validation/` but are only imported in `services/trading/backtest_replay.py`. The scheduler main loop in `services/scheduler/app.py` has no call to either function.
|
||||
|
||||
### Bug 1.5 — Quality Gate Permanently Failing
|
||||
`services/trading/model_quality_gate.py` queries `model_metric_snapshots` which is always empty (consequence of 1.4). Returns "no model metric snapshot available — defaulting to paper-only" every time.
|
||||
|
||||
### Bug 1.6 & 1.7 — Portfolio/Risk Snapshots
|
||||
The trading engine has `_persist_daily_snapshot()` but it only executes when the engine's main loop is actively processing trades. The trading-engine pod shows only health checks — its main loop isn't cycling because there are no active trade triggers flowing through it. No fallback capture exists in the scheduler.
|
||||
|
||||
### Bug 1.8 — Market Price Gaps
|
||||
`services/validation/prediction_snapshot.py` queries `market_snapshots` for price at prediction time. When Polygon rate limiting prevents market data fetches, no snapshot exists and `price_at_prediction` is NULL. 21% of snapshots affected.
|
||||
|
||||
### Bug 1.9 — Lake Publisher Idle
|
||||
The standalone `lake-publisher` deployment polls `stonks:beta:queue:lake_publish` but all services (broker-adapter, recommendation) import `services.lake_publisher.worker` directly and publish inline — never pushing to the Redis queue.
|
||||
|
||||
### Bug 1.10 — Order rejection_reason NULL
|
||||
`_INSERT_ORDER` SQL in `services/adapters/broker_service.py` doesn't include `rejection_reason` or `rejected_at` columns. The error is stored in `decision_trace` JSONB but the dedicated column stays NULL. The reconciliation path (`_reconcile_open_orders`) does set these columns, but initial persist does not.
|
||||
|
||||
## Fix Implementation
|
||||
|
||||
### Fix 1: Polygon Rate Limit Constant (Bug 1.1)
|
||||
|
||||
**File:** `services/scheduler/app.py`
|
||||
|
||||
Replace the hardcoded constant with an env-configurable value defaulting to 5:
|
||||
|
||||
```python
|
||||
# Before:
|
||||
POLYGON_GLOBAL_RATE_LIMIT: int = 45
|
||||
|
||||
# After:
|
||||
POLYGON_GLOBAL_RATE_LIMIT: int = int(os.getenv("POLYGON_GLOBAL_RATE_LIMIT", "5"))
|
||||
```
|
||||
|
||||
The existing `check_rate_limit()` function already implements per-minute windowed counting and skips sources once the limit is hit. By reducing the constant to match the free-tier limit, the system will naturally pace — enqueuing ~5 Polygon sources per minute across scheduler ticks (15s interval = 4 ticks/min). Skipped sources are retried next cycle.
|
||||
|
||||
**Validates:** Bugfix 2.1; Regression 3.1, 3.7
|
||||
|
||||
---
|
||||
|
||||
### Fix 2: v3_engine_enabled Config Query (Bug 1.2)
|
||||
|
||||
**File:** `services/aggregation/worker.py`
|
||||
|
||||
Replace the broken query and function:
|
||||
|
||||
```python
|
||||
# Before:
|
||||
_V3_ENGINE_FLAG_QUERY = """
|
||||
SELECT value FROM risk_configs WHERE key = 'v3_engine_enabled'
|
||||
"""
|
||||
|
||||
# After:
|
||||
_V3_ENGINE_FLAG_QUERY = """
|
||||
SELECT config->>'v3_engine_enabled' AS enabled
|
||||
FROM risk_configs
|
||||
WHERE name = 'default' AND active = TRUE
|
||||
LIMIT 1
|
||||
"""
|
||||
|
||||
async def _read_v3_flag(pool: asyncpg.Pool) -> bool:
|
||||
"""Read v3_engine_enabled from risk_configs JSONB. Default False on error."""
|
||||
try:
|
||||
row = await pool.fetchrow(_V3_ENGINE_FLAG_QUERY)
|
||||
if row and row["enabled"]:
|
||||
return row["enabled"].lower() in ("true", "1", "yes")
|
||||
return False
|
||||
except Exception as e:
|
||||
logger.warning("Failed to read v3_engine_enabled flag: %s", e)
|
||||
return False
|
||||
```
|
||||
|
||||
Reads from the `default` active risk_config's JSONB `config` field. Falls back to False (unchanged fail-safe).
|
||||
|
||||
**Validates:** Bugfix 2.2; Regression 3.2
|
||||
|
||||
---
|
||||
|
||||
### Fix 3: Validation Cycle in Scheduler (Bugs 1.3, 1.4, 1.5)
|
||||
|
||||
**File:** `services/scheduler/app.py`
|
||||
|
||||
Add a new periodic task (every ~240 ticks = ~60 minutes):
|
||||
|
||||
```python
|
||||
# New constant:
|
||||
VALIDATION_CYCLE_INTERVAL = int(os.getenv("VALIDATION_CYCLE_INTERVAL", "240"))
|
||||
|
||||
# New counter in main():
|
||||
validation_counter = 0
|
||||
|
||||
# In main loop after existing periodic tasks:
|
||||
validation_counter += 1
|
||||
if validation_counter >= VALIDATION_CYCLE_INTERVAL:
|
||||
validation_counter = 0
|
||||
await run_validation_cycle(pool)
|
||||
```
|
||||
|
||||
New function:
|
||||
|
||||
```python
|
||||
async def run_validation_cycle(pool: asyncpg.Pool) -> None:
|
||||
"""Run outcome evaluation and metric computation (hourly).
|
||||
|
||||
Requirements: 2.3, 2.4, 2.5
|
||||
"""
|
||||
from services.validation.outcome_evaluator import evaluate_matured_predictions
|
||||
from services.validation.metrics import compute_and_store_metric_snapshots
|
||||
|
||||
try:
|
||||
outcomes = await evaluate_matured_predictions(pool)
|
||||
logger.info("Validation: evaluated %d prediction outcomes", outcomes)
|
||||
except Exception:
|
||||
logger.exception("Validation: outcome evaluation failed")
|
||||
return # Skip metrics if outcomes failed
|
||||
|
||||
try:
|
||||
snapshots = await compute_and_store_metric_snapshots(pool)
|
||||
logger.info("Validation: computed %d metric snapshots", len(snapshots))
|
||||
except Exception:
|
||||
logger.exception("Validation: metric computation failed")
|
||||
```
|
||||
|
||||
**Validates:** Bugfix 2.3, 2.4, 2.5; Regression 3.3
|
||||
|
||||
---
|
||||
|
||||
### Fix 4: Daily Portfolio & Risk Snapshots (Bugs 1.6, 1.7)
|
||||
|
||||
**File:** `services/scheduler/app.py`
|
||||
|
||||
Add a daily snapshot task that runs every ~60 minutes but only captures once per day after 16:30 ET:
|
||||
|
||||
```python
|
||||
SNAPSHOT_CYCLE_INTERVAL = int(os.getenv("SNAPSHOT_CYCLE_INTERVAL", "240"))
|
||||
snapshot_counter = 0
|
||||
|
||||
# In main loop:
|
||||
snapshot_counter += 1
|
||||
if snapshot_counter >= SNAPSHOT_CYCLE_INTERVAL:
|
||||
snapshot_counter = 0
|
||||
await maybe_capture_daily_snapshots(pool)
|
||||
```
|
||||
|
||||
New function:
|
||||
|
||||
```python
|
||||
async def maybe_capture_daily_snapshots(pool: asyncpg.Pool) -> None:
|
||||
"""Capture portfolio and risk snapshots once daily after market close.
|
||||
|
||||
Requirements: 2.6, 2.7
|
||||
"""
|
||||
et_now = datetime.now(ZoneInfo("America/New_York"))
|
||||
|
||||
# Only after 4:30 PM ET
|
||||
if et_now.hour < 16 or (et_now.hour == 16 and et_now.minute < 30):
|
||||
return
|
||||
|
||||
today = et_now.date()
|
||||
|
||||
# Already captured today?
|
||||
existing = await pool.fetchval(
|
||||
"SELECT 1 FROM portfolio_snapshots WHERE snapshot_date = $1 LIMIT 1",
|
||||
today,
|
||||
)
|
||||
if existing:
|
||||
return
|
||||
|
||||
# Portfolio snapshot from positions + account data
|
||||
try:
|
||||
positions = await pool.fetch("SELECT * FROM positions WHERE quantity > 0")
|
||||
portfolio_value = sum(
|
||||
float(r["current_price"] or 0) * float(r["quantity"])
|
||||
for r in positions
|
||||
)
|
||||
unrealized_pnl = sum(float(r["unrealized_pnl"] or 0) for r in positions)
|
||||
|
||||
await pool.execute(
|
||||
"""INSERT INTO portfolio_snapshots
|
||||
(snapshot_date, portfolio_value, unrealized_pnl, positions)
|
||||
VALUES ($1, $2, $3, $4::jsonb)""",
|
||||
today, portfolio_value, unrealized_pnl,
|
||||
json.dumps([dict(r) for r in positions], default=str),
|
||||
)
|
||||
logger.info("Captured portfolio snapshot: value=%.2f", portfolio_value)
|
||||
except Exception:
|
||||
logger.exception("Failed to capture portfolio snapshot")
|
||||
|
||||
# Risk snapshot from daily activity
|
||||
try:
|
||||
daily_orders = await pool.fetchval(
|
||||
"SELECT count(*) FROM orders WHERE created_at::date = $1", today
|
||||
)
|
||||
daily_pnl = sum(float(r["unrealized_pnl"] or 0) for r in positions) if positions else 0.0
|
||||
|
||||
await pool.execute(
|
||||
"""INSERT INTO daily_risk_snapshots
|
||||
(account_id, snapshot_date, portfolio_value, daily_pnl, daily_trade_count)
|
||||
VALUES ((SELECT id FROM broker_accounts LIMIT 1), $1, $2, $3, $4)
|
||||
ON CONFLICT DO NOTHING""",
|
||||
today, portfolio_value, daily_pnl, daily_orders or 0,
|
||||
)
|
||||
logger.info("Captured risk snapshot: pnl=%.2f trades=%d", daily_pnl, daily_orders or 0)
|
||||
except Exception:
|
||||
logger.exception("Failed to capture risk snapshot")
|
||||
```
|
||||
|
||||
**Validates:** Bugfix 2.6, 2.7; Regression 3.10
|
||||
|
||||
---
|
||||
|
||||
### Fix 5: Prediction Price Fallback (Bug 1.8)
|
||||
|
||||
**File:** `services/validation/prediction_snapshot.py`
|
||||
|
||||
After the primary `market_snapshots` price lookup returns NULL, add a fallback:
|
||||
|
||||
```python
|
||||
# After market_snapshots lookup:
|
||||
if price_at_prediction is None:
|
||||
pos_row = await conn.fetchrow(
|
||||
"SELECT current_price FROM positions "
|
||||
"WHERE ticker = $1 AND current_price IS NOT NULL LIMIT 1",
|
||||
ticker,
|
||||
)
|
||||
if pos_row:
|
||||
price_at_prediction = float(pos_row["current_price"])
|
||||
```
|
||||
|
||||
Only covers tickers with open positions (currently 10). Acceptable tradeoff — most active tickers are the ones we hold.
|
||||
|
||||
**Validates:** Bugfix 2.8; Regression 3.4
|
||||
|
||||
---
|
||||
|
||||
### Fix 6: Lake Publisher Scale-Down (Bug 1.9)
|
||||
|
||||
**File:** `infra/helm/stonks-oracle/values.yaml`
|
||||
|
||||
```yaml
|
||||
# Change:
|
||||
replicas: 0
|
||||
```
|
||||
|
||||
Keeps the deployment definition intact for future use but schedules no pods.
|
||||
|
||||
**Validates:** Bugfix 2.9; Regression 3.5
|
||||
|
||||
---
|
||||
|
||||
### Fix 7: Order rejection_reason Population (Bug 1.10)
|
||||
|
||||
**File:** `services/adapters/broker_service.py`
|
||||
|
||||
Extend `_INSERT_ORDER` to include `rejection_reason` and `rejected_at`:
|
||||
|
||||
```python
|
||||
_INSERT_ORDER = """
|
||||
INSERT INTO orders (
|
||||
id, recommendation_id, broker_account_id, ticker, side, order_type,
|
||||
quantity, limit_price, stop_price, status, idempotency_key,
|
||||
broker_order_id, decision_trace, submitted_at, filled_at,
|
||||
fill_price, fill_quantity, rejection_reason, rejected_at
|
||||
) VALUES (
|
||||
$1::uuid, $2, $3::uuid, $4, $5, $6,
|
||||
$7, $8, $9, $10, $11,
|
||||
$12, $13::jsonb, $14, $15,
|
||||
$16, $17, $18, $19
|
||||
)
|
||||
ON CONFLICT (idempotency_key) DO UPDATE SET
|
||||
status = EXCLUDED.status,
|
||||
broker_order_id = EXCLUDED.broker_order_id,
|
||||
filled_at = EXCLUDED.filled_at,
|
||||
fill_price = EXCLUDED.fill_price,
|
||||
fill_quantity = EXCLUDED.fill_quantity,
|
||||
rejection_reason = COALESCE(EXCLUDED.rejection_reason, orders.rejection_reason),
|
||||
rejected_at = COALESCE(EXCLUDED.rejected_at, orders.rejected_at),
|
||||
updated_at = NOW()
|
||||
"""
|
||||
```
|
||||
|
||||
Update `persist_order()` to pass the new parameters:
|
||||
|
||||
```python
|
||||
rejection_reason = resp.error if resp.status == OrderStatus.REJECTED else None
|
||||
rejected_at = now if resp.status == OrderStatus.REJECTED else None
|
||||
# Add as params $18, $19
|
||||
```
|
||||
|
||||
**Validates:** Bugfix 2.10; Regression 3.6, 3.8
|
||||
|
||||
---
|
||||
|
||||
## Correctness Properties
|
||||
|
||||
Property 1: Rate limit compliance — After fix, the rolling 1-minute window for Polygon requests SHALL NOT exceed the configured limit (default 5). Existing `check_rate_limit()` windowed counter enforces this; we only change the threshold constant.
|
||||
|
||||
Property 2: Validation cycle completeness — `prediction_outcomes` row count SHALL grow monotonically after the first validation cycle runs. Each run finds matured snapshots not yet evaluated and persists outcomes.
|
||||
|
||||
Property 3: Metric snapshot freshness — `model_metric_snapshots` SHALL contain rows with `generated_at` within the last 2 hours after 2+ validation cycles. The quality gate can then evaluate against real data.
|
||||
|
||||
Property 4: Config read correctness — `_read_v3_flag()` SHALL return True when `risk_configs.config->>'v3_engine_enabled'` is `'true'` and False for all other values including NULL or missing key.
|
||||
|
||||
Property 5: Snapshot idempotency — `portfolio_snapshots` SHALL contain at most 1 row per `snapshot_date`. The `maybe_capture_daily_snapshots` function checks for existing rows before insert.
|
||||
|
||||
Property 6: Rejection reason preservation — Every order with `status = 'rejected'` persisted via `persist_order()` SHALL have a non-NULL `rejection_reason` extracted from the error response.
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
- **Unit tests:** Update `test_scheduler.py` with a test verifying `run_validation_cycle` is called after the counter threshold. Test `_read_v3_flag` with mocked JSONB config returning various values.
|
||||
- **Integration tests:** Verify `persist_order` with rejected status populates `rejection_reason` column.
|
||||
- **Manual verification post-deploy:**
|
||||
- `kubectl logs deployment/scheduler -n stonks-beta --tail=100 | grep Validation` shows outcome counts
|
||||
- `SELECT count(*) FROM prediction_outcomes` starts growing within 1 hour
|
||||
- `SELECT count(*) FROM model_metric_snapshots` populates after outcomes exist
|
||||
- Scheduler logs show significantly fewer "Rate limit hit" warnings
|
||||
- Aggregation logs no longer show "column value does not exist" error
|
||||
- After market close: `SELECT * FROM portfolio_snapshots WHERE snapshot_date = CURRENT_DATE` returns 1 row
|
||||
|
||||
## Glossary
|
||||
|
||||
| Term | Definition |
|
||||
|------|-----------|
|
||||
| Validation cycle | Hourly scheduler task: evaluate_matured_predictions → compute_and_store_metric_snapshots |
|
||||
| Quality gate | Threshold check on model_metric_snapshots that determines if trading can be promoted from paper to live |
|
||||
| Prediction snapshot | Frozen state of a recommendation at generation time (prices, evidence, scores) |
|
||||
| Outcome evaluation | Matching a matured prediction snapshot against realized market returns |
|
||||
| Polygon free tier | API plan with ~5 requests/minute rate limit |
|
||||
@@ -0,0 +1,69 @@
|
||||
# Implementation Plan: ops-pipeline-fixes
|
||||
|
||||
## Overview
|
||||
|
||||
Fix 10 operational bugs preventing the validation/calibration feedback loop from functioning and degrading ingestion throughput. Changes span scheduler (rate limiting + periodic tasks), aggregation worker (config query), broker service (rejection reason), prediction snapshot (price fallback), and Helm chart (dead pod removal).
|
||||
|
||||
## Tasks
|
||||
|
||||
- [x] 1. Fix Polygon global rate limit — In `services/scheduler/app.py`, replace `POLYGON_GLOBAL_RATE_LIMIT: int = 45` with `POLYGON_GLOBAL_RATE_LIMIT: int = int(os.getenv("POLYGON_GLOBAL_RATE_LIMIT", "5"))` to make it env-configurable and default to the free-tier limit
|
||||
- **Validates: Bugfix 2.1; Regression 3.1, 3.7**
|
||||
|
||||
- [x] 2. Fix v3_engine_enabled query — In `services/aggregation/worker.py`, replace `_V3_ENGINE_FLAG_QUERY` from `SELECT value FROM risk_configs WHERE key = 'v3_engine_enabled'` to `SELECT config->>'v3_engine_enabled' AS enabled FROM risk_configs WHERE name = 'default' AND active = TRUE LIMIT 1`, and rewrite `_read_v3_flag()` to parse the returned string (checking for "true"/"1"/"yes"), returning False for NULL/missing/error
|
||||
- **Validates: Bugfix 2.2; Regression 3.2**
|
||||
|
||||
- [x] 3. Add validation cycle constant and counter — In `services/scheduler/app.py`, add `VALIDATION_CYCLE_INTERVAL = int(os.getenv("VALIDATION_CYCLE_INTERVAL", "240"))` constant and `validation_counter = 0` initialization in `main()`
|
||||
- **Validates: Bugfix 2.3, 2.4**
|
||||
|
||||
- [x] 4. Implement run_validation_cycle function — In `services/scheduler/app.py`, implement `run_validation_cycle(pool)` that calls `evaluate_matured_predictions(pool)` followed by `compute_and_store_metric_snapshots(pool)`, with try/except logging for each and skipping metrics if outcomes fail
|
||||
- **Validates: Bugfix 2.3, 2.4, 2.5; Regression 3.3**
|
||||
|
||||
- [x] 5. Wire validation cycle into main loop — In `services/scheduler/app.py` main loop, add the counter increment and conditional call to `run_validation_cycle(pool)` after the existing `report_schedule_counter` block
|
||||
- **Validates: Bugfix 2.3, 2.4, 2.5**
|
||||
|
||||
- [x] 6. Add snapshot cycle constant and counter — In `services/scheduler/app.py`, add `SNAPSHOT_CYCLE_INTERVAL = int(os.getenv("SNAPSHOT_CYCLE_INTERVAL", "240"))` constant and `snapshot_counter = 0` initialization in `main()`
|
||||
- **Validates: Bugfix 2.6, 2.7**
|
||||
|
||||
- [x] 7. Implement maybe_capture_daily_snapshots function — In `services/scheduler/app.py`, implement `maybe_capture_daily_snapshots(pool)` that checks time (after 16:30 ET), checks idempotency (no existing row for today), queries positions table for portfolio value/unrealized PnL, and inserts into `portfolio_snapshots` and `daily_risk_snapshots`
|
||||
- **Validates: Bugfix 2.6, 2.7; Regression 3.10**
|
||||
|
||||
- [x] 8. Wire snapshot cycle into main loop — In `services/scheduler/app.py` main loop, add the counter increment and conditional call to `maybe_capture_daily_snapshots(pool)` after the validation counter block
|
||||
- **Validates: Bugfix 2.6, 2.7**
|
||||
|
||||
- [x] 9. Add prediction price fallback — In `services/validation/prediction_snapshot.py`, after the primary market_snapshots price lookup returns NULL for `price_at_prediction`, add a fallback query to positions table: `SELECT current_price FROM positions WHERE ticker = $1 AND current_price IS NOT NULL LIMIT 1`
|
||||
- **Validates: Bugfix 2.8; Regression 3.4**
|
||||
|
||||
- [x] 10. Scale down lake-publisher — In `infra/helm/stonks-oracle/values.yaml`, change the lake-publisher `replicas` from `1` to `0`
|
||||
- **Validates: Bugfix 2.9; Regression 3.5**
|
||||
|
||||
- [x] 11. Extend _INSERT_ORDER SQL — In `services/adapters/broker_service.py`, extend `_INSERT_ORDER` SQL to include `rejection_reason` and `rejected_at` as parameters $18 and $19, with COALESCE in the ON CONFLICT UPDATE clause to preserve existing values
|
||||
- **Validates: Bugfix 2.10; Regression 3.6, 3.8**
|
||||
|
||||
- [x] 12. Update persist_order parameters — In `services/adapters/broker_service.py`, update `persist_order()` to compute `rejection_reason = resp.error if resp.status == OrderStatus.REJECTED else None` and `rejected_at = now if resp.status == OrderStatus.REJECTED else None`, passing them as the final two parameters in the execute call
|
||||
- **Validates: Bugfix 2.10; Regression 3.6, 3.8**
|
||||
|
||||
- [x] 13. Lint and test — Run `.venv/bin/ruff check services/` and `.venv/bin/python -m pytest tests/ -x --tb=short -q` to verify no regressions
|
||||
- **Validates: Regression 3.1–3.10**
|
||||
|
||||
## Task Dependency Graph
|
||||
|
||||
```json
|
||||
{
|
||||
"waves": [
|
||||
{"tasks": [1, 2, 9, 10]},
|
||||
{"tasks": [3, 6, 11]},
|
||||
{"tasks": [4, 7, 12]},
|
||||
{"tasks": [5, 8]},
|
||||
{"tasks": [13]}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Tasks 1, 2, 9, 10 are fully independent. Tasks 3/6/11 set up constants needed by 4/7/12. Tasks 5/8 wire into the main loop after their functions exist. Task 13 validates everything last.
|
||||
|
||||
## Notes
|
||||
|
||||
- No database migrations required — all tables already exist with correct columns
|
||||
- All scheduler changes use the existing counter-based periodic task pattern already established for cleanup, aggregation, and report tasks
|
||||
- Lazy imports in `run_validation_cycle` avoid circular imports and keep scheduler startup fast
|
||||
- The `maybe_capture_daily_snapshots` idempotency check prevents duplicate rows on scheduler restart
|
||||
@@ -0,0 +1 @@
|
||||
{"specId": "f5d99301-94ef-4dc2-8ba4-ccefeee7ecba", "workflowType": "requirements-first", "specType": "bugfix"}
|
||||
@@ -0,0 +1,51 @@
|
||||
# Bugfix Requirements Document
|
||||
|
||||
## Introduction
|
||||
|
||||
Five operational bugs in the stonks-beta deployment degrade pipeline health: 1,809 documents stuck in `parsed` status due to recovery batch limits, 26.5% of prediction snapshots missing prices due to incomplete fallback chains, 64% sell bias from uncalibrated NuExtract3 sentiment outputs, idle signal-engine consuming resources while doing nothing, and a quality gate stuck in paper-only mode due to an overly strict staleness threshold interacting with the NULL price problem.
|
||||
|
||||
## Bug Analysis
|
||||
|
||||
### Current Behavior (Defect)
|
||||
|
||||
1.1 WHEN the `recover_stale_documents` task runs with 1,809+ documents stuck in `parsed` status THEN the system only processes 100 per cycle (every ~5 minutes), requiring 90+ cycles (~7.5 hours) to clear the backlog while new documents may continue accumulating
|
||||
|
||||
1.2 WHEN a prediction snapshot is created for a ticker without an open position AND without recent market_snapshots data THEN the system stores NULL in `price_at_prediction` because the fallback chain stops at the positions table (26.5% of snapshots affected — 33,324 of 125,590)
|
||||
|
||||
1.3 WHEN the outcome evaluator encounters a prediction snapshot with NULL `price_at_prediction` THEN the system skips the snapshot entirely, creating a validation blind spot where 26.5% of predictions are never evaluated
|
||||
|
||||
1.4 WHEN the aggregation pipeline processes NuExtract3 extraction outputs THEN the system passes raw `impact_score` and `sentiment` values directly into signal weighting without any distribution normalization, resulting in systematic negative bias producing 64% sell / 23% watch / 12% buy recommendations
|
||||
|
||||
1.5 WHEN the signal-engine pod starts with `dual_pipeline_enabled=False` THEN the system enters an infinite sleep loop consuming CPU (100m request / 500m limit) and memory (128Mi request / 256Mi limit) while producing zero signal evaluations
|
||||
|
||||
1.6 WHEN the quality gate checks `model_metric_snapshots` freshness with a 24-hour staleness threshold AND the validation cycle skips all predictions due to NULL prices (Bug 1.2/1.3) THEN the system permanently defaults to paper-only mode because no fresh metric snapshots are ever generated
|
||||
|
||||
### Expected Behavior (Correct)
|
||||
|
||||
2.1 WHEN the scheduler detects more than 100 documents stuck in `parsed` status older than the threshold THEN the system SHALL increase the batch limit for recovery processing (up to 500 per cycle) and provide a one-time management command to bulk-recover the existing backlog without waiting for periodic sweeps
|
||||
|
||||
2.2 WHEN a prediction snapshot is created and no price is available from market_snapshots (exact time) or positions table THEN the system SHALL query `market_snapshots` with a wider time window (last 24 hours of bar data for the ticker) as an additional fallback before accepting NULL
|
||||
|
||||
2.3 WHEN backfilling existing prediction snapshots with NULL `price_at_prediction` THEN the system SHALL use the extended fallback chain (market_snapshots within 24h of `generated_at`, then positions) to populate prices retroactively via a migration script
|
||||
|
||||
2.4 WHEN the aggregation pipeline computes signal weights from impact records THEN the system SHALL apply z-score normalization to `impact_score` values relative to the rolling 7-day distribution of impact records for the same ticker, preventing systematic model bias from dominating the directional signal
|
||||
|
||||
2.5 WHEN the signal-engine deployment is not ready for production use (`dual_pipeline_enabled=False`) THEN the system SHALL be scaled to 0 replicas in the Helm values files (beta, paper, live) to eliminate wasted CPU, memory, and any GPU time-slice allocations
|
||||
|
||||
2.6 WHEN the quality gate evaluates metric snapshot freshness during the bootstrapping period THEN the system SHALL use a 48-hour staleness threshold (instead of 24h) to tolerate gaps while the validation cycle ramps up after Bug 1.2/1.3 are fixed
|
||||
|
||||
### Unchanged Behavior (Regression Prevention)
|
||||
|
||||
3.1 WHEN documents enter `parsed` status and are processed within the normal threshold window (< 240 minutes) THEN the system SHALL CONTINUE TO leave them for the extraction queue consumer without interference from the recovery task
|
||||
|
||||
3.2 WHEN a prediction snapshot is created and market_snapshots contains a recent bar for the ticker THEN the system SHALL CONTINUE TO use the primary `market_snapshots` close price without invoking any fallback
|
||||
|
||||
3.3 WHEN the aggregation pipeline processes tickers with balanced sentiment distributions (equal bullish/bearish evidence) THEN the system SHALL CONTINUE TO produce neutral/mixed recommendations without artificial skew from the normalization step
|
||||
|
||||
3.4 WHEN the signal-engine is re-enabled in the future (dual_pipeline_enabled=True with replicas > 0) THEN the system SHALL CONTINUE TO function correctly with its existing queue-based architecture and configuration loading
|
||||
|
||||
3.5 WHEN the quality gate evaluates a metric snapshot that is less than 48 hours old and meets all threshold criteria THEN the system SHALL CONTINUE TO promote recommendations to live_eligible mode per existing threshold logic
|
||||
|
||||
3.6 WHEN the outcome evaluator processes prediction snapshots with valid (non-NULL) prices THEN the system SHALL CONTINUE TO evaluate them normally and produce prediction_outcomes records
|
||||
|
||||
3.7 WHEN the `retry_failed_extractions` task handles documents in `extraction_failed` status THEN the system SHALL CONTINUE TO process them on the existing cadence and logic without interference from the parsed-document recovery changes
|
||||
@@ -0,0 +1,320 @@
|
||||
# Pipeline Health Fixes — Bugfix Design
|
||||
|
||||
## Overview
|
||||
|
||||
Five operational bugs degrade stonks-beta pipeline health. This design formalizes the bug conditions, expected fixes, and validation strategy for each:
|
||||
|
||||
1. **Stuck Parsed Docs** — `recover_stale_documents()` batch limit of 100 is too low for 1,809 stuck documents; increase to 500 and lower the stale threshold to 30 minutes.
|
||||
2. **Extended Price Fallback** — Prediction snapshots missing prices (26.5%) because the fallback chain stops at `positions`; add a third fallback querying `market_snapshots` within 24h.
|
||||
3. **Sentiment Z-Score Normalization** — Raw NuExtract3 `impact_score` values produce 64% sell bias; normalize using 7-day rolling z-scores per ticker before signal weighting.
|
||||
4. **Signal Engine Scale Down** — Idle signal-engine pods consume resources; set replicas to 0 in all Helm values files.
|
||||
5. **Quality Gate Threshold** — 24h staleness threshold permanently locks quality gate to paper-only; relax to 48h.
|
||||
|
||||
## Glossary
|
||||
|
||||
- **Bug_Condition (C)**: The specific conditions under which each bug manifests
|
||||
- **Property (P)**: The desired correct behavior after the fix is applied
|
||||
- **Preservation**: Existing behavior that must remain unchanged after the fix
|
||||
- **`recover_stale_documents()`**: Function in `services/scheduler/app.py` that re-enqueues documents stuck in `parsed` status
|
||||
- **`STALE_PARSED_THRESHOLD_MINUTES`**: Constant (currently 240) controlling how long a document must be stuck before recovery
|
||||
- **`fetch_latest_close_price()`**: Function in `services/validation/prediction_snapshot.py` that queries `market_snapshots` for the most recent bar
|
||||
- **`compute_signal_weight()`**: Function in `services/aggregation/scoring.py` that computes combined signal weight from recency, credibility, novelty, confidence, and impact
|
||||
- **`QualityGateConfig.max_snapshot_age_hours`**: Threshold in `services/trading/model_quality_gate.py` controlling when the quality gate defaults to paper-only
|
||||
|
||||
## Bug Details
|
||||
|
||||
### Bug Condition
|
||||
|
||||
The pipeline health degradation manifests across five independent conditions:
|
||||
|
||||
**Formal Specification:**
|
||||
```
|
||||
FUNCTION isBugCondition(input)
|
||||
INPUT: input of type PipelineState
|
||||
OUTPUT: boolean
|
||||
|
||||
-- Bug 1: Parsed docs stuck beyond batch capacity
|
||||
RETURN (input.stuckParsedDocCount > 100
|
||||
AND input.recoveryBatchLimit == 100
|
||||
AND input.docStaleMinutes >= 240)
|
||||
-- Bug 2: Price fallback chain incomplete
|
||||
OR (input.tickerPrice IS NULL
|
||||
AND input.positionPrice IS NULL
|
||||
AND input.marketSnapshotWithin24h IS NOT NULL)
|
||||
-- Bug 3: Raw impact scores without normalization
|
||||
OR (input.impactScoreUsedRaw == TRUE
|
||||
AND input.ticker7dStddev > 0)
|
||||
-- Bug 4: Signal engine running idle
|
||||
OR (input.signalEngineReplicas > 0
|
||||
AND input.dualPipelineEnabled == FALSE)
|
||||
-- Bug 5: Quality gate threshold too strict
|
||||
OR (input.snapshotAgeHours > 24
|
||||
AND input.snapshotAgeHours <= 48
|
||||
AND input.maxSnapshotAgeConfig == 24)
|
||||
END FUNCTION
|
||||
```
|
||||
|
||||
### Examples
|
||||
|
||||
- **Bug 1**: 1,809 documents in `parsed` status older than 4 hours. At 100/cycle every 5 minutes, clearing takes 90+ cycles (~7.5h). With 500/batch, it takes 4 cycles (~20 min).
|
||||
- **Bug 2**: Ticker PLTR has no open position and `fetch_latest_close_price` returns NULL, but `market_snapshots` has a bar from 3 hours ago that could serve as price.
|
||||
- **Bug 3**: NuExtract3 outputs `impact_score` values clustered around -0.3 to -0.1 for a ticker. Without normalization, `weighted_sentiment_average()` systematically produces negative signals → 64% sell recommendations.
|
||||
- **Bug 4**: signal-engine pod starts, detects `dual_pipeline_enabled=False`, enters infinite sleep loop consuming 100m CPU request / 128Mi memory request.
|
||||
- **Bug 5**: Quality gate reads `model_metric_snapshots`, finds the most recent is 26h old (because validation skips NULL-price predictions), fails staleness check, forces paper-only mode permanently.
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
### Preservation Requirements
|
||||
|
||||
**Unchanged Behaviors:**
|
||||
- Documents entering `parsed` status and processed within the normal threshold window (< 30 min after fix) are left alone for the extraction queue consumer
|
||||
- Primary price lookup via `fetch_latest_close_price()` (exact time match from `market_snapshots`) continues as the first-choice price source
|
||||
- Tickers with balanced sentiment distributions continue to produce neutral/mixed recommendations without artificial skew
|
||||
- Signal-engine's queue-based architecture and configuration loading remain functional when re-enabled with replicas > 0
|
||||
- Quality gate threshold logic for snapshots younger than 48h and meeting all criteria continues to promote to `live_eligible`
|
||||
- Outcome evaluator continues to process prediction snapshots with valid (non-NULL) prices normally
|
||||
- `retry_failed_extractions` task continues on its existing cadence without interference
|
||||
|
||||
**Scope:**
|
||||
All inputs that do NOT match the bug conditions above should be completely unaffected by these fixes. The fixes are additive (new fallback path, wider batch, normalization layer) or config-only (replica count, threshold constant).
|
||||
|
||||
## Hypothesized Root Cause
|
||||
|
||||
### Bug 1: Stuck Parsed Docs
|
||||
- **Batch limit too small**: The `LIMIT 100` in the SQL query caps recovery throughput at 100 docs per scheduler cycle (~5 min). When a Redis crash orphans thousands of documents, the recovery rate cannot keep up with the backlog.
|
||||
- **Threshold too conservative**: `STALE_PARSED_THRESHOLD_MINUTES = 240` (4 hours) means documents must be stuck for 4 hours before recovery kicks in. A 30-minute threshold would catch orphans much faster.
|
||||
|
||||
### Bug 2: Incomplete Fallback Chain
|
||||
- **Missing time-window query**: `fetch_latest_close_price()` only checks `market_snapshots` for an exact timestamp match. When market data ingestion is delayed or the prediction happens outside market hours, no exact match exists.
|
||||
- **Positions-only fallback**: The positions table fallback only works for tickers with an active position. 26.5% of snapshots are for tickers without positions.
|
||||
|
||||
### Bug 3: Uncalibrated Impact Scores
|
||||
- **No distribution normalization**: NuExtract3 model outputs are passed raw into `compute_signal_weight()` via `impact_score` parameter. The model has a systematic negative bias in its output distribution that is not corrected.
|
||||
- **Per-ticker variance ignored**: Different tickers receive different volume/types of news, producing different impact_score distributions. A global normalization would be insufficient.
|
||||
|
||||
### Bug 4: Idle Signal Engine
|
||||
- **Replicas set to 1 by default**: `values.yaml` defines `signalEngine.replicas: 1` regardless of whether the dual pipeline feature is enabled. The pod starts, detects the feature is off, and sleeps forever.
|
||||
|
||||
### Bug 5: Overly Strict Staleness
|
||||
- **24h threshold too tight during bootstrapping**: The `max_snapshot_age_hours = 24` default assumes the validation cycle runs frequently. When Bug 2/3 cause most predictions to be skipped, metric snapshots aren't generated, and the 24h window expires.
|
||||
|
||||
## Correctness Properties
|
||||
|
||||
Property 1: Bug Condition — Stuck Parsed Docs Recovery
|
||||
|
||||
_For any_ set of documents stuck in `parsed` status longer than 30 minutes, the fixed `recover_stale_documents()` function SHALL process up to 500 documents per cycle, reducing backlog clearance time by 5x compared to the previous 100-document limit.
|
||||
|
||||
**Validates: Requirements 2.1**
|
||||
|
||||
Property 2: Bug Condition — Extended Price Fallback
|
||||
|
||||
_For any_ prediction snapshot where `fetch_latest_close_price()` returns NULL and the `positions` table has no price, but `market_snapshots` contains a bar for the ticker within 24 hours of the prediction time, the fixed code SHALL use that bar's close price as `price_at_prediction`.
|
||||
|
||||
**Validates: Requirements 2.2, 2.3**
|
||||
|
||||
Property 3: Bug Condition — Sentiment Z-Score Normalization
|
||||
|
||||
_For any_ set of `document_impact_records` for a ticker, the fixed aggregation pipeline SHALL normalize `impact_score` values using the 7-day rolling mean and standard deviation for that ticker before passing them into signal weight computation, preventing systematic model bias.
|
||||
|
||||
**Validates: Requirements 2.4**
|
||||
|
||||
Property 4: Bug Condition — Signal Engine Scale Down
|
||||
|
||||
_For any_ Helm deployment where `dual_pipeline_enabled=False`, the fixed Helm values SHALL specify `signalEngine.replicas: 0`, preventing the pod from being scheduled and consuming resources.
|
||||
|
||||
**Validates: Requirements 2.5**
|
||||
|
||||
Property 5: Bug Condition — Quality Gate Threshold
|
||||
|
||||
_For any_ model metric snapshot that is between 24h and 48h old, the fixed quality gate SHALL NOT reject it as stale, allowing the system to remain in non-paper mode during the bootstrapping period.
|
||||
|
||||
**Validates: Requirements 2.6**
|
||||
|
||||
Property 6: Preservation — Normal Document Processing
|
||||
|
||||
_For any_ document that enters `parsed` status and is processed within 30 minutes, the fixed `recover_stale_documents()` function SHALL NOT interfere with normal extraction queue processing, preserving the existing pipeline flow.
|
||||
|
||||
**Validates: Requirements 3.1, 3.7**
|
||||
|
||||
Property 7: Preservation — Primary Price Path
|
||||
|
||||
_For any_ prediction snapshot where `fetch_latest_close_price()` returns a valid price, the fixed code SHALL use that price directly without invoking any fallback, preserving the primary price lookup behavior.
|
||||
|
||||
**Validates: Requirements 3.2**
|
||||
|
||||
Property 8: Preservation — Balanced Sentiment
|
||||
|
||||
_For any_ ticker with a balanced sentiment distribution (equal bullish/bearish evidence), the z-score normalization SHALL produce values centered around 0, preserving neutral/mixed recommendation output without artificial skew.
|
||||
|
||||
**Validates: Requirements 3.3**
|
||||
|
||||
Property 9: Preservation — Quality Gate Valid Snapshots
|
||||
|
||||
_For any_ model metric snapshot younger than 48h that meets all threshold criteria, the fixed quality gate SHALL continue to promote recommendations to `live_eligible` mode per existing logic.
|
||||
|
||||
**Validates: Requirements 3.5, 3.6**
|
||||
|
||||
## Fix Implementation
|
||||
|
||||
### Changes Required
|
||||
|
||||
**Bug 1: Stuck Parsed Docs Recovery**
|
||||
|
||||
**File**: `services/scheduler/app.py`
|
||||
|
||||
**Function**: `recover_stale_documents()`
|
||||
|
||||
**Specific Changes**:
|
||||
1. **Lower stale threshold**: Change `STALE_PARSED_THRESHOLD_MINUTES` from `240` to `30` — documents stuck longer than 30 minutes are likely orphaned
|
||||
2. **Increase batch limit**: Change `LIMIT 100` to `LIMIT 500` in the SQL query
|
||||
3. **Update enqueued TTL**: Change `_ENQUEUED_TTL` from `14400` (4h) to `3600` (1h) to match the new threshold
|
||||
|
||||
---
|
||||
|
||||
**Bug 2: Extended Price Fallback**
|
||||
|
||||
**File**: `services/validation/prediction_snapshot.py`
|
||||
|
||||
**Function**: `create_prediction_snapshot()`
|
||||
|
||||
**Specific Changes**:
|
||||
1. **Add market_snapshots time-window fallback**: After the positions fallback fails, query `market_snapshots` for the most recent bar within 24h of the current time for the ticker
|
||||
2. **SQL query**: `SELECT close FROM market_snapshots WHERE ticker = $1 AND timestamp >= NOW() - INTERVAL '24 hours' ORDER BY timestamp DESC LIMIT 1`
|
||||
3. **Log the fallback**: Add info-level logging when the extended fallback is used
|
||||
|
||||
**New File**: `scripts/backfill_snapshot_prices.py`
|
||||
|
||||
**Purpose**: One-time backfill script to populate `price_at_prediction` for existing NULL snapshots using the extended fallback chain.
|
||||
|
||||
**Approach**:
|
||||
1. Query all `prediction_snapshots` where `price_at_prediction IS NULL`
|
||||
2. For each, attempt: `market_snapshots` within 24h of `generated_at`, then `positions` table
|
||||
3. Update the row with the found price
|
||||
4. Report statistics (found via market_snapshots, found via positions, still NULL)
|
||||
|
||||
---
|
||||
|
||||
**Bug 3: Sentiment Z-Score Normalization**
|
||||
|
||||
**File**: `services/aggregation/worker.py` (or new helper in `services/aggregation/scoring.py`)
|
||||
|
||||
**Function**: New function `normalize_impact_scores()` called before `compute_signal_weight()`
|
||||
|
||||
**Specific Changes**:
|
||||
1. **Add normalization function**: Compute 7-day rolling mean and stddev of `impact_score` per ticker from `document_impact_records`
|
||||
2. **Formula**: `normalized = (raw - mean_7d) / max(stddev_7d, 0.1)` — the 0.1 floor prevents division by near-zero stddev for low-activity tickers
|
||||
3. **Integration point**: In the aggregation loop (around line 440 of worker.py), normalize `imp.impact_score` before passing to `compute_signal_weight()` and `WeightedSignal`
|
||||
4. **Fallback**: If fewer than 5 records exist in the 7-day window, use the raw score (insufficient data for meaningful normalization)
|
||||
5. **Query**: `SELECT AVG(impact_score) as mean, STDDEV(impact_score) as stddev FROM document_impact_records WHERE ticker = $1 AND created_at >= NOW() - INTERVAL '7 days'`
|
||||
|
||||
---
|
||||
|
||||
**Bug 4: Signal Engine Scale Down**
|
||||
|
||||
**Files**: `infra/helm/stonks-oracle/values.yaml`, `values-beta.yaml`, `values-paper.yaml`
|
||||
|
||||
**Specific Changes**:
|
||||
1. **values.yaml**: Change `signalEngine.replicas` from `1` to `0`
|
||||
2. **values-beta.yaml**: Add `signalEngine.replicas: 0` under `services:`
|
||||
3. **values-paper.yaml**: Add `signalEngine.replicas: 0` under `services:`
|
||||
|
||||
---
|
||||
|
||||
**Bug 5: Quality Gate Threshold**
|
||||
|
||||
**File**: `services/trading/model_quality_gate.py`
|
||||
|
||||
**Class**: `QualityGateConfig`
|
||||
|
||||
**Specific Changes**:
|
||||
1. **Change default**: `max_snapshot_age_hours: int = 48` (was 24)
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Validation Approach
|
||||
|
||||
The testing strategy follows a two-phase approach: first, surface counterexamples that demonstrate the bug on unfixed code, then verify the fix works correctly and preserves existing behavior.
|
||||
|
||||
### Exploratory Bug Condition Checking
|
||||
|
||||
**Goal**: Surface counterexamples that demonstrate the bugs BEFORE implementing the fixes. Confirm or refute the root cause analysis.
|
||||
|
||||
**Test Plan**: Write tests that exercise each bug condition on the unfixed code to observe failures.
|
||||
|
||||
**Test Cases**:
|
||||
1. **Batch Overflow Test**: Create 600 documents in `parsed` status older than threshold, run `recover_stale_documents()`, assert only 100 are processed (will demonstrate Bug 1)
|
||||
2. **Price Fallback Gap Test**: Call `create_prediction_snapshot()` for a ticker with no position and no exact market_snapshots match, assert `price_at_prediction` is NULL (will demonstrate Bug 2)
|
||||
3. **Sentiment Bias Test**: Generate 50 impact records with systematic negative bias (mean=-0.3, stddev=0.1), compute weighted signals, assert directional signal is negative (will demonstrate Bug 3)
|
||||
4. **Quality Gate Staleness Test**: Set most recent metric snapshot to 26h ago, evaluate quality gate, assert it fails (will demonstrate Bug 5)
|
||||
|
||||
**Expected Counterexamples**:
|
||||
- Bug 1: Only 100 of 600 documents recovered per cycle
|
||||
- Bug 2: `price_at_prediction` stored as NULL despite market data existing within 24h
|
||||
- Bug 3: Weighted sentiment average heavily negative despite mixed underlying events
|
||||
- Bug 5: Quality gate returns `passed=False` with reason containing "stale"
|
||||
|
||||
### Fix Checking
|
||||
|
||||
**Goal**: Verify that for all inputs where the bug condition holds, the fixed function produces the expected behavior.
|
||||
|
||||
**Pseudocode:**
|
||||
```
|
||||
FOR ALL input WHERE isBugCondition(input) DO
|
||||
result := fixedFunction(input)
|
||||
ASSERT expectedBehavior(result)
|
||||
END FOR
|
||||
```
|
||||
|
||||
**Per-bug fix checks:**
|
||||
- Bug 1: `recover_stale_documents()` processes up to 500 docs with 30-min threshold
|
||||
- Bug 2: Extended fallback returns a price when `market_snapshots` has data within 24h
|
||||
- Bug 3: Normalized impact scores have mean ≈ 0 and stddev ≈ 1 for active tickers
|
||||
- Bug 4: `kubectl get pods` shows 0 signal-engine pods
|
||||
- Bug 5: Quality gate passes for snapshots 24–48h old that meet metric thresholds
|
||||
|
||||
### Preservation Checking
|
||||
|
||||
**Goal**: Verify that for all inputs where the bug condition does NOT hold, the fixed function produces the same result as the original function.
|
||||
|
||||
**Pseudocode:**
|
||||
```
|
||||
FOR ALL input WHERE NOT isBugCondition(input) DO
|
||||
ASSERT originalFunction(input) = fixedFunction(input)
|
||||
END FOR
|
||||
```
|
||||
|
||||
**Testing Approach**: Property-based testing is recommended for preservation checking because:
|
||||
- It generates many test cases automatically across the input domain
|
||||
- It catches edge cases that manual unit tests might miss
|
||||
- It provides strong guarantees that behavior is unchanged for all non-buggy inputs
|
||||
|
||||
**Test Plan**: Observe behavior on UNFIXED code first for normal inputs, then write property-based tests capturing that behavior.
|
||||
|
||||
**Test Cases**:
|
||||
1. **Normal Doc Processing Preservation**: Documents < 30 min old are never touched by recovery
|
||||
2. **Primary Price Preservation**: When `fetch_latest_close_price()` succeeds, no fallback is invoked
|
||||
3. **Balanced Sentiment Preservation**: Tickers with symmetric impact_score distributions produce neutral signals after normalization
|
||||
4. **Quality Gate Normal Preservation**: Snapshots < 48h old and meeting thresholds still pass
|
||||
5. **Failed Extraction Preservation**: `retry_failed_extractions()` behavior unchanged
|
||||
|
||||
### Unit Tests
|
||||
|
||||
- Test `recover_stale_documents()` with various document counts (0, 50, 500, 1000)
|
||||
- Test extended price fallback with market_snapshots at various time offsets (1h, 12h, 23h, 25h)
|
||||
- Test z-score normalization with known distributions (mean=0, mean=-0.5, stddev=0, stddev=0.05)
|
||||
- Test quality gate with snapshot ages at boundary (23h, 24h, 47h, 48h, 49h)
|
||||
- Test backfill script with mixed NULL/non-NULL snapshots
|
||||
|
||||
### Property-Based Tests
|
||||
|
||||
- Generate random document ages and counts, verify recovery processes correct subset (> 30 min old, up to 500)
|
||||
- Generate random ticker price scenarios, verify fallback chain ordering is preserved (primary → positions → market_snapshots_24h → NULL)
|
||||
- Generate random impact_score distributions per ticker, verify normalized output has bounded variance and zero-centered mean
|
||||
- Generate random snapshot ages, verify quality gate accepts [0, 48h) and rejects [48h, ∞)
|
||||
|
||||
### Integration Tests
|
||||
|
||||
- End-to-end: create documents in `parsed` status, run scheduler cycle, verify extraction queue populated
|
||||
- End-to-end: create prediction snapshot for ticker without position, verify price populated from market_snapshots
|
||||
- End-to-end: run full aggregation cycle with biased NuExtract3 outputs, verify recommendation direction is not systematically biased
|
||||
- Helm template render: verify signal-engine deployment has 0 replicas in all value files
|
||||
@@ -0,0 +1,174 @@
|
||||
# Implementation Plan
|
||||
|
||||
## Overview
|
||||
|
||||
Bugfix implementation for five pipeline health issues: stuck parsed docs, missing price fallback, uncalibrated sentiment scores, idle signal-engine pods, and overly strict quality gate threshold. Tasks follow the exploratory bugfix workflow: explore bugs via tests, preserve existing behavior, implement fixes, validate.
|
||||
|
||||
## Tasks
|
||||
|
||||
- [x] 1. Write bug condition exploration test
|
||||
- **Property 1: Bug Condition** - Pipeline Health Degradation
|
||||
- **CRITICAL**: This test MUST FAIL on unfixed code - failure confirms the bugs exist
|
||||
- **DO NOT attempt to fix the test or the code when it fails**
|
||||
- **NOTE**: This test encodes the expected behavior - it will validate the fix when it passes after implementation
|
||||
- **GOAL**: Surface counterexamples that demonstrate all five bugs exist
|
||||
- **Scoped PBT Approach**: Scope properties to the concrete failing cases for each bug condition
|
||||
- Test file: `tests/test_pbt_pipeline_health_bug_condition.py`
|
||||
- **Bug 1 - Batch Overflow**: Create 600 documents in `parsed` status older than 30 min, run `recover_stale_documents()`, assert up to 500 are recovered per cycle (will FAIL on unfixed code which caps at 100)
|
||||
- **Bug 2 - Price Fallback Gap**: Call `create_prediction_snapshot()` for ticker with no position and no exact market_snapshots match but data within 24h exists, assert `price_at_prediction` is NOT NULL (will FAIL on unfixed code which returns NULL)
|
||||
- **Bug 3 - Sentiment Bias**: Generate 50 impact records with systematic negative bias (mean=-0.3, stddev=0.1), compute weighted signals via aggregation, assert normalized output is zero-centered (will FAIL on unfixed code which passes raw scores)
|
||||
- **Bug 5 - Quality Gate Staleness**: Set most recent metric snapshot to 26h ago, evaluate quality gate, assert it passes (will FAIL on unfixed code which rejects at 24h)
|
||||
- Run tests on UNFIXED code
|
||||
- **EXPECTED OUTCOME**: Tests FAIL (this is correct - it proves the bugs exist)
|
||||
- Document counterexamples: batch capped at 100, price stored as NULL, sentiment heavily negative, quality gate returns `passed=False`
|
||||
- Mark task complete when tests are written, run, and failures are documented
|
||||
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.6_
|
||||
|
||||
- [x] 2. Write preservation property tests (BEFORE implementing fix)
|
||||
- **Property 2: Preservation** - Pipeline Behavior Unchanged for Non-Bug Inputs
|
||||
- **IMPORTANT**: Follow observation-first methodology
|
||||
- Test file: `tests/test_pbt_pipeline_health_preservation.py`
|
||||
- **Normal Doc Processing**: Observe that documents < 30 min old are never touched by `recover_stale_documents()` on unfixed code. Write property: for all documents with age < 30 min, recovery task does NOT enqueue them.
|
||||
- **Primary Price Path**: Observe that when `fetch_latest_close_price()` returns a valid price, no fallback is invoked. Write property: for all tickers where primary price exists, result equals primary price.
|
||||
- **Balanced Sentiment**: Observe that tickers with symmetric impact_score distributions (mean ≈ 0) produce neutral signals. Write property: for all impact_score sets with mean ≈ 0, normalized output remains centered around 0.
|
||||
- **Quality Gate Normal**: Observe that snapshots < 48h old meeting thresholds pass the quality gate. Write property: for all snapshot ages in [0, 48h) meeting metric criteria, quality gate returns `passed=True`.
|
||||
- **Failed Extraction Independence**: Observe `retry_failed_extractions()` behavior is unaffected. Write property: for all documents in `extraction_failed` status, retry logic unchanged.
|
||||
- Run tests on UNFIXED code
|
||||
- **EXPECTED OUTCOME**: Tests PASS (this confirms baseline behavior to preserve)
|
||||
- Mark task complete when tests are written, run, and passing on unfixed code
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.5, 3.6, 3.7_
|
||||
|
||||
- [x] 3. Fix: Signal Engine Scale Down (Helm values)
|
||||
|
||||
- [x] 3.1 Set signal-engine replicas to 0 in all Helm values files
|
||||
- In `infra/helm/stonks-oracle/values.yaml`: change `signalEngine.replicas` from `1` to `0`
|
||||
- In `infra/helm/stonks-oracle/values-beta.yaml`: add/set `signalEngine.replicas: 0` under `services:`
|
||||
- In `infra/helm/stonks-oracle/values-paper.yaml`: add/set `signalEngine.replicas: 0` under `services:`
|
||||
- _Bug_Condition: input.signalEngineReplicas > 0 AND input.dualPipelineEnabled == FALSE_
|
||||
- _Expected_Behavior: signalEngine.replicas == 0 when dual pipeline disabled_
|
||||
- _Preservation: Signal-engine architecture remains functional when re-enabled with replicas > 0_
|
||||
- _Requirements: 2.5, 3.4_
|
||||
|
||||
- [x] 4. Fix: Quality Gate Threshold Relaxation
|
||||
|
||||
- [x] 4.1 Change max_snapshot_age_hours default from 24 to 48
|
||||
- File: `services/trading/model_quality_gate.py`
|
||||
- In `QualityGateConfig` class, change `max_snapshot_age_hours: int = 24` to `max_snapshot_age_hours: int = 48`
|
||||
- _Bug_Condition: input.snapshotAgeHours > 24 AND input.snapshotAgeHours <= 48 AND input.maxSnapshotAgeConfig == 24_
|
||||
- _Expected_Behavior: Quality gate accepts snapshots up to 48h old_
|
||||
- _Preservation: Snapshots < 48h meeting criteria continue to promote to live_eligible_
|
||||
- _Requirements: 2.6, 3.5_
|
||||
|
||||
- [x] 5. Fix: Stuck Parsed Docs Recovery
|
||||
|
||||
- [x] 5.1 Lower STALE_PARSED_THRESHOLD_MINUTES from 240 to 30
|
||||
- File: `services/scheduler/app.py`
|
||||
- Change constant: `STALE_PARSED_THRESHOLD_MINUTES = 30`
|
||||
- Documents stuck longer than 30 minutes are likely orphaned
|
||||
- _Requirements: 2.1_
|
||||
|
||||
- [x] 5.2 Increase recovery batch LIMIT from 100 to 500
|
||||
- File: `services/scheduler/app.py`
|
||||
- In `recover_stale_documents()` SQL query, change `LIMIT 100` to `LIMIT 500`
|
||||
- _Requirements: 2.1_
|
||||
|
||||
- [x] 5.3 Update _ENQUEUED_TTL from 14400 to 3600
|
||||
- File: `services/scheduler/app.py`
|
||||
- Change `_ENQUEUED_TTL = 3600` (1 hour, matching the new recovery cadence)
|
||||
- _Bug_Condition: input.stuckParsedDocCount > 100 AND input.recoveryBatchLimit == 100 AND input.docStaleMinutes >= 240_
|
||||
- _Expected_Behavior: Recovery processes up to 500 docs per cycle with 30-min threshold_
|
||||
- _Preservation: Documents < 30 min old left alone for extraction queue consumer_
|
||||
- _Requirements: 2.1, 3.1, 3.7_
|
||||
|
||||
- [x] 6. Fix: Extended Price Fallback
|
||||
|
||||
- [x] 6.1 Add market_snapshots 24h time-window fallback to create_prediction_snapshot()
|
||||
- File: `services/validation/prediction_snapshot.py`
|
||||
- After positions fallback fails, query: `SELECT close FROM market_snapshots WHERE ticker = $1 AND timestamp >= NOW() - INTERVAL '24 hours' ORDER BY timestamp DESC LIMIT 1`
|
||||
- Add info-level logging when extended fallback is used
|
||||
- _Bug_Condition: input.tickerPrice IS NULL AND input.positionPrice IS NULL AND input.marketSnapshotWithin24h IS NOT NULL_
|
||||
- _Expected_Behavior: Use market_snapshots bar close price as price_at_prediction_
|
||||
- _Preservation: Primary fetch_latest_close_price() path unchanged when it returns a valid price_
|
||||
- _Requirements: 2.2, 3.2_
|
||||
|
||||
- [x] 6.2 Create backfill script scripts/backfill_snapshot_prices.py
|
||||
- Query all `prediction_snapshots` where `price_at_prediction IS NULL`
|
||||
- For each, attempt: `market_snapshots` within 24h of `generated_at`, then `positions` table
|
||||
- Update row with found price
|
||||
- Report statistics: found via market_snapshots, found via positions, still NULL
|
||||
- _Requirements: 2.3_
|
||||
|
||||
- [x] 7. Fix: Sentiment Z-Score Normalization
|
||||
|
||||
- [x] 7.1 Add normalize_impact_scores() function
|
||||
- File: `services/aggregation/scoring.py` (new helper function)
|
||||
- Query 7-day mean and stddev per ticker: `SELECT AVG(impact_score) as mean, STDDEV(impact_score) as stddev FROM document_impact_records WHERE ticker = $1 AND created_at >= NOW() - INTERVAL '7 days'`
|
||||
- Formula: `normalized = (raw - mean_7d) / max(stddev_7d, 0.1)`
|
||||
- Fallback: if fewer than 5 records in 7-day window, return raw score unchanged
|
||||
- The 0.1 floor prevents division by near-zero stddev for low-activity tickers
|
||||
- _Requirements: 2.4_
|
||||
|
||||
- [x] 7.2 Integrate normalization into aggregation loop
|
||||
- File: `services/aggregation/worker.py`
|
||||
- Before `compute_signal_weight()` call (around line 440), normalize `imp.impact_score` via `normalize_impact_scores()`
|
||||
- Pass normalized value into `compute_signal_weight()` and `WeightedSignal`
|
||||
- _Bug_Condition: input.impactScoreUsedRaw == TRUE AND input.ticker7dStddev > 0_
|
||||
- _Expected_Behavior: Normalized impact scores with mean ≈ 0, stddev ≈ 1 for active tickers_
|
||||
- _Preservation: Tickers with balanced distributions continue to produce neutral signals_
|
||||
- _Requirements: 2.4, 3.3_
|
||||
|
||||
- [x] 8. Verify fixes pass all tests
|
||||
|
||||
- [x] 8.1 Verify bug condition exploration test now passes
|
||||
- **Property 1: Expected Behavior** - Pipeline Health Bugs Resolved
|
||||
- **IMPORTANT**: Re-run the SAME test from task 1 - do NOT write a new test
|
||||
- The test from task 1 encodes the expected behavior for all five bugs
|
||||
- Run `tests/test_pbt_pipeline_health_bug_condition.py`
|
||||
- **EXPECTED OUTCOME**: Test PASSES (confirms bugs are fixed)
|
||||
- _Requirements: 2.1, 2.2, 2.4, 2.6_
|
||||
|
||||
- [x] 8.2 Verify preservation tests still pass
|
||||
- **Property 2: Preservation** - Pipeline Behavior Unchanged for Non-Bug Inputs
|
||||
- **IMPORTANT**: Re-run the SAME tests from task 2 - do NOT write new tests
|
||||
- Run `tests/test_pbt_pipeline_health_preservation.py`
|
||||
- **EXPECTED OUTCOME**: Tests PASS (confirms no regressions)
|
||||
- Confirm all preservation properties still hold after fixes
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.5, 3.6, 3.7_
|
||||
|
||||
- [x] 9. Lint and final validation
|
||||
- Run `.venv/bin/ruff check services/` and fix any lint errors
|
||||
- Run `.venv/bin/python -m pytest tests/ -x --tb=short -q` to confirm full test suite passes
|
||||
- Verify Helm template renders correctly with 0 signal-engine replicas
|
||||
- _Requirements: all_
|
||||
|
||||
- [x] 10. Checkpoint - Ensure all tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
## Task Dependency Graph
|
||||
|
||||
```json
|
||||
{
|
||||
"waves": [
|
||||
{"tasks": ["1", "2"]},
|
||||
{"tasks": ["3", "4"]},
|
||||
{"tasks": ["5"]},
|
||||
{"tasks": ["6"]},
|
||||
{"tasks": ["7"]},
|
||||
{"tasks": ["8"]},
|
||||
{"tasks": ["9"]},
|
||||
{"tasks": ["10"]}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Tasks 3, 4 are independent config changes (no code deps).
|
||||
Task 5 is independent but task 6 builds on the price fallback concept.
|
||||
Task 7 is the most complex (new function + integration).
|
||||
Tasks 8-10 must run after all fixes are applied.
|
||||
|
||||
## Notes
|
||||
|
||||
- Bug 4 (signal engine) is validated by Helm template rendering, not a unit test
|
||||
- The backfill script (6.2) is a one-time operation, not covered by recurring tests
|
||||
- Preservation tests use Hypothesis with `@settings(max_examples=100)` per project conventions
|
||||
- Test files follow `test_pbt_*` naming convention per project standards
|
||||
@@ -0,0 +1 @@
|
||||
{"specId": "b595d834-7e72-4fab-87a9-65c92115a069", "workflowType": "requirements-first", "specType": "feature"}
|
||||
@@ -0,0 +1,732 @@
|
||||
# Design Document — Signal Math Upgrade
|
||||
|
||||
## Overview
|
||||
|
||||
This design upgrades the Stonks Oracle signal processing pipeline from deterministic heuristic formulas to a probabilistic, regime-aware, and adaptive mathematical framework. The upgrade spans all pipeline stages — signal scoring, trend assembly, macro impact, competitive signals, trend projection, and recommendation generation — while preserving the existing `WeightedSignal` abstraction, three-layer architecture, database schema, and dataclass interfaces.
|
||||
|
||||
The core transformation replaces:
|
||||
- **Binary confidence gate** → smooth sigmoid transition
|
||||
- **Weighted sentiment average** → Bayesian log-likelihood accumulation with Beta posterior
|
||||
- **Fixed recency decay** → adaptive event-specific half-lives
|
||||
- **Linear macro exposure** → multiplicative compounding exposure
|
||||
- **Additive macro integration** → conditional multiplicative modifiers
|
||||
- **Simple contradiction ratio** → weighted disagreement entropy
|
||||
- **Heuristic trend confidence** → Bayesian posterior variance
|
||||
- **Threshold-based direction** → entropy-based mixed signal detection
|
||||
- **Simple momentum** → exponentially weighted momentum with volatility scaling
|
||||
- **Confidence/strength gates** → expected value recommendation gate
|
||||
- **Fixed relationship transfer** → graph-distance attenuated competitive signals
|
||||
|
||||
All changes are gated behind a `probabilistic_scoring_enabled` feature flag in `risk_configs`, allowing incremental rollout with instant rollback. New outputs (P_bull, α, β, entropy, regime, EV) are stored in existing JSONB columns — no database migrations required.
|
||||
|
||||
### Design Rationale
|
||||
|
||||
Markets are fundamentally probabilistic and regime-dependent. The current pipeline collapses rich evidence into binary sentiment labels and fixed-weight averages, losing uncertainty structure. A Bayesian framework preserves the full posterior distribution, enabling the system to distinguish between "strongly bullish" and "weakly bullish with high uncertainty" — a distinction that directly impacts position sizing and risk management.
|
||||
|
||||
The regime detector adapts scoring thresholds to market conditions (panic vs. trending vs. mean-reverting), and the expected value gate ensures recommendations only proceed when the risk-adjusted outcome is positive. Together, these changes transform the pipeline from a sentiment aggregator into a probabilistic forecasting engine.
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
### High-Level Pipeline Flow
|
||||
|
||||
The upgraded pipeline maintains the existing three-layer architecture but introduces new computation stages within each layer. The feature flag controls which computation path is taken at each stage.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph "Layer 1: Company Signals"
|
||||
A[Document Intelligence Records] --> B[Signal Scorer]
|
||||
B --> |"probabilistic=false"| C1[Binary Gate + Fixed Decay]
|
||||
B --> |"probabilistic=true"| C2[Sigmoid Gate + Adaptive Decay<br/>+ Info Gain + Source Accuracy]
|
||||
C1 --> D[WeightedSignal list]
|
||||
C2 --> D
|
||||
end
|
||||
|
||||
subgraph "Layer 2: Macro Signals"
|
||||
E[Global Events] --> F[Macro Scorer]
|
||||
F --> |"probabilistic=false"| G1[Linear Weighted Sum]
|
||||
F --> |"probabilistic=true"| G2[Multiplicative Exposure]
|
||||
G1 --> H[Macro WeightedSignals]
|
||||
G2 --> H
|
||||
end
|
||||
|
||||
subgraph "Layer 3: Competitive Signals"
|
||||
I[Pattern Matcher] --> J[Signal Propagation]
|
||||
J --> |"probabilistic=false"| K1[Flat Transfer Strength]
|
||||
J --> |"probabilistic=true"| K2[Graph-Distance Attenuation]
|
||||
K1 --> L[Competitive WeightedSignals]
|
||||
K2 --> L
|
||||
end
|
||||
|
||||
subgraph "Regime Detection (new)"
|
||||
M[Market Data] --> N[Regime Detector]
|
||||
N --> O{Regime Classification}
|
||||
O --> P[trend-following / panic / mean-reversion / uncertainty]
|
||||
end
|
||||
|
||||
subgraph "Trend Assembly"
|
||||
D --> Q[Merge Signals]
|
||||
H --> |"probabilistic=false"| Q
|
||||
H --> |"probabilistic=true"| R[Conditional Macro Modifier]
|
||||
R --> Q
|
||||
L --> Q
|
||||
Q --> S[Trend Assembler]
|
||||
S --> |"probabilistic=false"| T1[Heuristic Confidence + Threshold Direction]
|
||||
S --> |"probabilistic=true"| T2[Bayesian Posterior + Entropy Direction<br/>+ Regime-Adjusted Thresholds]
|
||||
P --> T2
|
||||
T1 --> U[TrendSummary]
|
||||
T2 --> U
|
||||
end
|
||||
|
||||
subgraph "Projection"
|
||||
U --> V[Projection Engine]
|
||||
V --> |"probabilistic=false"| W1[Simple Momentum]
|
||||
V --> |"probabilistic=true"| W2[EW Momentum + Vol Scaling]
|
||||
W1 --> X[TrendProjection]
|
||||
W2 --> X
|
||||
end
|
||||
|
||||
subgraph "Recommendation"
|
||||
U --> Y[Recommendation Engine]
|
||||
X --> Y
|
||||
Y --> |"probabilistic=false"| Z1[Confidence + Strength Gates]
|
||||
Y --> |"probabilistic=true"| Z2[EV Gate + Existing Gates]
|
||||
Z1 --> AA[Recommendation]
|
||||
Z2 --> AA
|
||||
end
|
||||
```
|
||||
|
||||
### Feature Flag Control Flow
|
||||
|
||||
The feature flag `probabilistic_scoring_enabled` is read from the `risk_configs` table's `config` JSONB column at the start of each aggregation cycle. It propagates through all pipeline stages via the existing `AggregationConfig` dataclass.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant W as Worker (aggregate_company)
|
||||
participant DB as PostgreSQL (risk_configs)
|
||||
participant S as Signal Scorer
|
||||
participant T as Trend Assembler
|
||||
participant R as Recommendation Engine
|
||||
|
||||
W->>DB: SELECT config FROM risk_configs WHERE active=TRUE
|
||||
DB-->>W: {"macro_enabled": true, "competitive_enabled": true, "probabilistic_scoring_enabled": false}
|
||||
W->>W: Log pipeline mode (heuristic or probabilistic)
|
||||
W->>S: compute_signal_weight(..., probabilistic=flag)
|
||||
S-->>W: WeightedSignal (with or without Bayesian fields)
|
||||
W->>T: assemble_trend_summary(..., probabilistic=flag)
|
||||
T-->>W: TrendSummary (with or without entropy/regime)
|
||||
W->>R: evaluate_eligibility(..., probabilistic=flag)
|
||||
R-->>W: Recommendation (with or without EV gate)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Components and Interfaces
|
||||
|
||||
### New Modules
|
||||
|
||||
| Module | File | Responsibility |
|
||||
|--------|------|----------------|
|
||||
| Bayesian Accumulator | `services/aggregation/bayesian.py` | Log-likelihood accumulation, Beta posterior, P_bull, Bayesian confidence |
|
||||
| Regime Detector | `services/aggregation/regime.py` | EMA computation, volatility ratio, regime classification, threshold adjustment |
|
||||
| Adaptive Decay | integrated into `scoring.py` | Event-specific half-life computation from impact, surprise, market reaction |
|
||||
| Information Gain | integrated into `scoring.py` | Surprise weighting from event type base rates |
|
||||
| Source Accuracy | `services/aggregation/source_accuracy.py` | Historical prediction accuracy tracking per source |
|
||||
| Entropy Detector | integrated into `bayesian.py` | Shannon entropy for mixed signal detection |
|
||||
| EV Gate | integrated into `eligibility.py` | Expected value computation for recommendation eligibility |
|
||||
|
||||
### Modified Modules
|
||||
|
||||
| Module | File | Changes |
|
||||
|--------|------|---------|
|
||||
| Signal Scorer | `services/aggregation/scoring.py` | Sigmoid gate, info gain factor, adaptive decay, regime multiplier, source accuracy factor |
|
||||
| Trend Assembler | `services/aggregation/worker.py` | Bayesian confidence, entropy-based direction, regime-adjusted thresholds, entropy-based contradiction |
|
||||
| Contradiction | `services/aggregation/contradiction.py` | Weighted disagreement entropy replacing minority/majority ratio |
|
||||
| Macro Scorer | `services/aggregation/interpolation.py` | Multiplicative exposure formula, conditional integration mode |
|
||||
| Competitive Scorer | `services/aggregation/signal_propagation.py` | Graph-distance attenuation with historical correlation |
|
||||
| Projection Engine | `services/aggregation/projection.py` | Exponentially weighted momentum, volatility scaling |
|
||||
| Recommendation | `services/recommendation/eligibility.py` | EV gate, P_bull-based position sizing adjustments |
|
||||
| Config | `services/shared/config.py` | New probabilistic config parameters |
|
||||
| Schemas | `services/shared/schemas.py` | Optional new fields on TrendSummary, Recommendation |
|
||||
|
||||
### Component Interface Details
|
||||
|
||||
#### 1. Bayesian Accumulator (`services/aggregation/bayesian.py`)
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class BayesianPosterior:
|
||||
"""Bayesian posterior state from signal accumulation."""
|
||||
p_bull: float # σ(L_t), bullish probability [0, 1]
|
||||
alpha: float # Beta distribution α parameter (≥ 1.0)
|
||||
beta: float # Beta distribution β parameter (≥ 1.0)
|
||||
log_likelihood: float # Raw log-likelihood accumulation L_t
|
||||
bayesian_confidence: float # 1 - 4αβ/(α+β)², [0, 1]
|
||||
entropy: float # Shannon entropy H, [0, 1]
|
||||
signal_count: int # Number of signals processed
|
||||
|
||||
# Uninformative prior (no evidence)
|
||||
PRIOR = BayesianPosterior(
|
||||
p_bull=0.5, alpha=1.0, beta=1.0,
|
||||
log_likelihood=0.0, bayesian_confidence=0.0,
|
||||
entropy=1.0, signal_count=0,
|
||||
)
|
||||
|
||||
|
||||
def compute_bayesian_posterior(
|
||||
signals: list[WeightedSignal],
|
||||
) -> BayesianPosterior:
|
||||
"""Accumulate weighted signals into a Bayesian posterior.
|
||||
|
||||
Computes:
|
||||
- Log-likelihood: L_t = Σ(w_i · s_i)
|
||||
- Bullish probability: P_bull = σ(L_t)
|
||||
- Beta posterior: α = 1 + W_bull, β = 1 + W_bear
|
||||
- Bayesian confidence: C = 1 - 4αβ/(α+β)²
|
||||
- Shannon entropy: H = -p·log₂(p) - (1-p)·log₂(1-p)
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def compute_entropy(p_bull: float) -> float:
|
||||
"""Shannon entropy H = -p·log₂(p) - (1-p)·log₂(1-p).
|
||||
|
||||
Returns value in [0, 1]. Maximum at p=0.5, zero at p=0 or p=1.
|
||||
Handles edge cases p=0 and p=1 by returning 0.0.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### 2. Regime Detector (`services/aggregation/regime.py`)
|
||||
|
||||
```python
|
||||
class MarketRegime(str, Enum):
|
||||
TREND_FOLLOWING = "trend_following"
|
||||
PANIC = "panic"
|
||||
MEAN_REVERSION = "mean_reversion"
|
||||
UNCERTAINTY = "uncertainty"
|
||||
|
||||
|
||||
@dataclass(frozen=True)
|
||||
class RegimeClassification:
|
||||
"""Result of regime detection for a ticker."""
|
||||
regime: MarketRegime
|
||||
trend_indicator: float # R = sign(EMA_20 - EMA_100)
|
||||
volatility_ratio: float # V_r = σ_20 / σ_100
|
||||
bullish_threshold: float # Adjusted ±threshold for direction
|
||||
bearish_threshold: float
|
||||
contradiction_penalty_multiplier: float # 0.4 default, 0.6 for uncertainty
|
||||
|
||||
|
||||
@dataclass(frozen=True)
|
||||
class RegimeConfig:
|
||||
ema_short_period: int = 20
|
||||
ema_long_period: int = 100
|
||||
vol_short_period: int = 20
|
||||
vol_long_period: int = 100
|
||||
panic_vol_ratio: float = 1.5
|
||||
trend_vol_ratio: float = 1.2
|
||||
mean_reversion_vol_ratio: float = 1.0
|
||||
default_threshold: float = 0.15
|
||||
panic_threshold: float = 0.10
|
||||
mean_reversion_threshold: float = 0.20
|
||||
uncertainty_contradiction_multiplier: float = 0.6
|
||||
|
||||
|
||||
def classify_regime(
|
||||
closing_prices: list[float],
|
||||
returns: list[float],
|
||||
config: RegimeConfig = RegimeConfig(),
|
||||
) -> RegimeClassification:
|
||||
"""Classify market regime from price and return history.
|
||||
|
||||
Requires at least 100 days of price history for EMA_100.
|
||||
Falls back to UNCERTAINTY when data is insufficient.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def compute_ema(values: list[float], period: int) -> float:
|
||||
"""Compute exponential moving average over the last `period` values."""
|
||||
...
|
||||
```
|
||||
|
||||
#### 3. Source Accuracy Tracker (`services/aggregation/source_accuracy.py`)
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class SourceAccuracy:
|
||||
"""Per-source historical prediction accuracy."""
|
||||
source_id: str
|
||||
accuracy_ratio: float # [0, 1] fraction of correct directional calls
|
||||
sample_count: int # Number of signals with known outcomes
|
||||
last_updated: datetime
|
||||
|
||||
@property
|
||||
def accuracy_factor(self) -> float:
|
||||
"""Multiplicative factor for credibility weight.
|
||||
|
||||
Returns 1.0 (neutral) when sample_count < 10.
|
||||
Otherwise scales linearly from 0.5 (0% accuracy) to 1.5 (100% accuracy).
|
||||
"""
|
||||
if self.sample_count < 10:
|
||||
return 1.0
|
||||
return 0.5 + self.accuracy_ratio
|
||||
|
||||
|
||||
async def fetch_source_accuracy(
|
||||
pool: asyncpg.Pool,
|
||||
source_ids: list[str],
|
||||
) -> dict[str, SourceAccuracy]:
|
||||
"""Fetch accuracy metrics for a batch of sources."""
|
||||
...
|
||||
|
||||
|
||||
async def update_source_accuracy(
|
||||
pool: asyncpg.Pool,
|
||||
source_id: str,
|
||||
realized_outcomes: list[tuple[str, float]], # (predicted_direction, actual_7d_return)
|
||||
) -> None:
|
||||
"""Update accuracy metrics for a source based on realized price data."""
|
||||
...
|
||||
```
|
||||
|
||||
#### 4. Extended ScoringConfig
|
||||
|
||||
New fields added to the existing `ScoringConfig` dataclass in `scoring.py`:
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class ScoringConfig:
|
||||
# ... existing fields preserved ...
|
||||
|
||||
# Probabilistic scoring toggle (mirrors feature flag for local use)
|
||||
probabilistic: bool = False
|
||||
|
||||
# Sigmoid gate parameters
|
||||
sigmoid_steepness: float = 5.0 # k in σ(k·(x - midpoint))
|
||||
sigmoid_midpoint: float = 0.5 # midpoint of sigmoid transition
|
||||
|
||||
# Information gain parameters
|
||||
info_gain_lambda: float = 0.3 # scaling parameter λ
|
||||
info_gain_max: float = 3.0 # maximum clamp for info gain factor
|
||||
default_base_rate: float = 0.1 # fallback when event type rate unknown
|
||||
|
||||
# Adaptive decay parameters (β scaling factors)
|
||||
adaptive_decay_impact_scale: float = 1.0 # max β_impact
|
||||
adaptive_decay_surprise_scale: float = 1.0 # max β_surprise at r=3.0
|
||||
adaptive_decay_market_scale: float = 0.5 # max β_market_reaction
|
||||
|
||||
# Regime multiplier parameters
|
||||
regime_return_weight: float = 0.15 # coefficient for |z_r|
|
||||
regime_volume_weight: float = 0.10 # coefficient for |z_v|
|
||||
regime_multiplier_max: float = 2.5 # M_regime ceiling
|
||||
```
|
||||
|
||||
#### 5. Extended WeightedSignal
|
||||
|
||||
The existing `WeightedSignal` dataclass gains optional fields:
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class WeightedSignal:
|
||||
"""A document intelligence reference paired with its computed weight."""
|
||||
document_id: str
|
||||
weight: SignalWeight
|
||||
sentiment_value: float
|
||||
impact_score: float
|
||||
|
||||
# New optional fields for probabilistic mode
|
||||
info_gain_factor: float = 1.0 # r = 1 + λ·(-log₂ P(event_type))
|
||||
source_accuracy_factor: float = 1.0 # [0.5, 1.5] from historical accuracy
|
||||
adaptive_half_life: float | None = None # τ_i when adaptive decay is active
|
||||
```
|
||||
|
||||
#### 6. Extended SignalWeight
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class SignalWeight:
|
||||
"""Breakdown of a document's aggregation weight."""
|
||||
recency: float
|
||||
credibility: float
|
||||
novelty_bonus: float
|
||||
confidence_gate: float
|
||||
market_ctx_multiplier: float
|
||||
combined: float
|
||||
|
||||
# New optional fields for probabilistic mode
|
||||
sigmoid_gate: float | None = None # Smooth gate value [0, 1]
|
||||
info_gain_factor: float = 1.0 # Surprise multiplier
|
||||
source_accuracy_factor: float = 1.0 # Historical accuracy multiplier
|
||||
regime_multiplier: float | None = None # M_regime replacing M_context
|
||||
```
|
||||
|
||||
#### 7. Extended TrendSummary
|
||||
|
||||
New optional fields on the existing Pydantic model:
|
||||
|
||||
```python
|
||||
class TrendSummary(BaseModel):
|
||||
# ... all existing fields preserved ...
|
||||
|
||||
# New optional fields for probabilistic mode
|
||||
p_bull: float | None = None # Bayesian bullish probability
|
||||
alpha: float | None = None # Beta posterior α
|
||||
beta_param: float | None = None # Beta posterior β (named to avoid shadowing)
|
||||
bayesian_confidence: float | None = None # 1 - 4αβ/(α+β)²
|
||||
entropy: float | None = None # Shannon entropy H
|
||||
regime: str | None = None # Market regime classification
|
||||
pipeline_mode: str = "heuristic" # "heuristic" or "probabilistic"
|
||||
```
|
||||
|
||||
#### 8. Extended Recommendation
|
||||
|
||||
```python
|
||||
class Recommendation(BaseModel):
|
||||
# ... all existing fields preserved ...
|
||||
|
||||
# New optional fields for probabilistic mode
|
||||
expected_value: float | None = None # EV = P_bull·R_up - P_bear·R_down
|
||||
p_bull: float | None = None # Bayesian bullish probability used
|
||||
pipeline_mode: str = "heuristic" # "heuristic" or "probabilistic"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data Models
|
||||
|
||||
### Database Storage Strategy
|
||||
|
||||
All new mathematical outputs are stored in existing JSONB columns. No new database migrations are required.
|
||||
|
||||
#### trend_windows table
|
||||
|
||||
The `market_context` JSONB column (currently stores volatility/volume data) is extended to include probabilistic outputs:
|
||||
|
||||
```json
|
||||
{
|
||||
"volatility": 1.23,
|
||||
"volume_change_pct": 45.2,
|
||||
"price_change_pct": -2.1,
|
||||
"probabilistic": {
|
||||
"p_bull": 0.72,
|
||||
"alpha": 8.3,
|
||||
"beta": 3.1,
|
||||
"log_likelihood": 0.94,
|
||||
"bayesian_confidence": 0.61,
|
||||
"entropy": 0.42,
|
||||
"regime": "trend_following",
|
||||
"regime_volatility_ratio": 0.85,
|
||||
"pipeline_mode": "probabilistic",
|
||||
"contradiction_entropy": 0.31,
|
||||
"macro_modifier": 1.15
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### recommendations table
|
||||
|
||||
The existing `invalidation_conditions` JSONB column stores recommendation-level data. The new EV and probabilistic fields are stored in a new key within the existing decision trace flow. Since recommendations don't have a dedicated metadata JSONB column, we add the probabilistic fields to the thesis text and store structured data in the `risk_checks` JSONB column of the `recommendation_evaluations` table:
|
||||
|
||||
```json
|
||||
{
|
||||
"ev": 0.0082,
|
||||
"p_bull": 0.72,
|
||||
"r_up": 0.034,
|
||||
"r_down": 0.012,
|
||||
"pipeline_mode": "probabilistic",
|
||||
"ev_threshold": 0.005
|
||||
}
|
||||
```
|
||||
|
||||
#### risk_configs table
|
||||
|
||||
The `config` JSONB column gains the new feature flag:
|
||||
|
||||
```json
|
||||
{
|
||||
"macro_enabled": true,
|
||||
"competitive_enabled": true,
|
||||
"probabilistic_scoring_enabled": false
|
||||
}
|
||||
```
|
||||
|
||||
#### source_accuracy table (new — Requirement 4)
|
||||
|
||||
This is the one new database table required, stored via a migration:
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS source_accuracy (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
source_id VARCHAR(200) NOT NULL,
|
||||
accuracy_ratio FLOAT NOT NULL DEFAULT 0.5,
|
||||
sample_count INTEGER NOT NULL DEFAULT 0,
|
||||
last_updated TIMESTAMPTZ NOT NULL DEFAULT NOW(),
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
|
||||
UNIQUE(source_id)
|
||||
);
|
||||
CREATE INDEX idx_source_accuracy_source ON source_accuracy(source_id);
|
||||
```
|
||||
|
||||
Note: This is the only schema addition. All other new outputs use existing JSONB columns.
|
||||
|
||||
### Event Type Base Rates
|
||||
|
||||
Information gain computation requires empirical base rates for event types. These are stored as a configuration constant (not in the database) and can be tuned over time:
|
||||
|
||||
```python
|
||||
EVENT_TYPE_BASE_RATES: dict[str, float] = {
|
||||
"earnings": 0.25, # Quarterly, common
|
||||
"product_launch": 0.10, # Moderately rare
|
||||
"regulatory": 0.08, # Somewhat rare
|
||||
"legal": 0.05, # Rare
|
||||
"m_and_a": 0.03, # Very rare
|
||||
"management_change": 0.06,
|
||||
"partnership": 0.12,
|
||||
"market_expansion": 0.09,
|
||||
"restructuring": 0.04,
|
||||
"dividend": 0.15,
|
||||
}
|
||||
DEFAULT_BASE_RATE = 0.1 # For unknown event types
|
||||
```
|
||||
|
||||
### Configuration Hierarchy
|
||||
|
||||
```
|
||||
risk_configs.config (DB, runtime)
|
||||
└── probabilistic_scoring_enabled: bool
|
||||
└── AggregationConfig.probabilistic: bool (in-memory)
|
||||
└── ScoringConfig.probabilistic: bool (per-cycle)
|
||||
├── scoring.py: sigmoid vs binary gate
|
||||
├── scoring.py: adaptive vs fixed decay
|
||||
├── scoring.py: info gain factor
|
||||
├── scoring.py: regime multiplier vs market context
|
||||
├── worker.py: Bayesian vs heuristic confidence
|
||||
├── worker.py: entropy vs threshold direction
|
||||
├── contradiction.py: entropy vs ratio
|
||||
├── interpolation.py: multiplicative vs linear
|
||||
├── signal_propagation.py: graph-distance vs flat
|
||||
├── projection.py: EW momentum vs simple
|
||||
└── eligibility.py: EV gate vs threshold-only
|
||||
```
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Correctness Properties
|
||||
|
||||
*A property is a characteristic or behavior that should hold true across all valid executions of a system — essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
|
||||
|
||||
The following properties were derived from the acceptance criteria through systematic prework analysis. Each property is universally quantified and maps to specific requirements. Redundant properties were consolidated during reflection (e.g., requirements 17.1–17.7 duplicate properties already stated in requirements 1–15).
|
||||
|
||||
### Property 1: Sigmoid Gate Monotonicity
|
||||
|
||||
*For any* two extraction confidence values x₁, x₂ ∈ [0.0, 1.0] where x₁ ≤ x₂, the sigmoid gate σ(5·(x₁ - 0.5)) SHALL be less than or equal to σ(5·(x₂ - 0.5)). Higher confidence always produces equal or higher gate values.
|
||||
|
||||
**Validates: Requirements 2.6, 17.1**
|
||||
|
||||
### Property 2: Beta Posterior Evidence Accumulation
|
||||
|
||||
*For any* sequence of weighted signal sets where each successive set contains one additional signal, the sum α + β of the Beta posterior parameters SHALL increase monotonically. Evidence always accumulates — adding a signal never reduces the total evidence mass.
|
||||
|
||||
**Validates: Requirements 1.3, 17.2**
|
||||
|
||||
### Property 3: Bayesian Confidence Symmetry and Divergence
|
||||
|
||||
*For any* Beta posterior with parameters α, β ≥ 1.0, the Bayesian confidence C = 1 - 4αβ/(α+β)² SHALL equal 0.0 when α = β (maximum uncertainty) and SHALL increase monotonically as the ratio max(α/β, β/α) increases. Confidence reflects evidence concentration, not evidence volume.
|
||||
|
||||
**Validates: Requirements 1.4, 17.3**
|
||||
|
||||
### Property 4: Bayesian Posterior Round-Trip Consistency
|
||||
|
||||
*For any* set of weighted signals with uniform weights, computing the Beta posterior and extracting the mean P_bull = α/(α+β) SHALL produce a value within 0.05 of σ(L_t) where L_t is the log-likelihood accumulation. The two probabilistic representations are consistent.
|
||||
|
||||
**Validates: Requirements 1.7, 17.7**
|
||||
|
||||
### Property 5: Adaptive Decay Lower Bound
|
||||
|
||||
*For any* valid combination of impact_score ∈ [0, 1], information gain factor r ∈ [1.0, 3.0], and market context multiplier ∈ [1.0, 1.45], the adaptive half-life τ_i SHALL be greater than or equal to the base half-life τ_base. Adaptive decay is always slower or equal to fixed decay, never faster.
|
||||
|
||||
**Validates: Requirements 5.7, 17.4**
|
||||
|
||||
### Property 6: Information Gain Monotonicity
|
||||
|
||||
*For any* two event type base rates p₁, p₂ ∈ (0, 1] where p₁ < p₂, the information gain factor r(p₁) SHALL be greater than or equal to r(p₂). Rarer events always receive higher surprise weight.
|
||||
|
||||
**Validates: Requirements 3.5**
|
||||
|
||||
### Property 7: Multiplicative Macro Exposure Monotonicity
|
||||
|
||||
*For any* overlap configuration (O_geo, O_supply, O_commodity, O_sector) and any dimension k where O_k = 0, setting O_k to any positive value SHALL increase the total macro impact score. Multi-dimensional exposure always compounds — it never reduces impact.
|
||||
|
||||
**Validates: Requirements 10.7, 17.5**
|
||||
|
||||
### Property 8: Shannon Entropy Range and Maximum
|
||||
|
||||
*For any* bullish probability P_bull ∈ (0, 1), the Shannon entropy H = -P_bull·log₂(P_bull) - (1-P_bull)·log₂(1-P_bull) SHALL be in the range (0, 1], with the maximum value of 1.0 occurring at P_bull = 0.5.
|
||||
|
||||
**Validates: Requirements 9.7**
|
||||
|
||||
### Property 9: Contradiction Entropy Monotonicity
|
||||
|
||||
*For any* set of weighted signals containing both positive and negative sentiment signals, the contradiction entropy score SHALL increase monotonically as the weight distribution f_pos approaches 0.5 (equal split). More balanced disagreement always produces higher contradiction.
|
||||
|
||||
**Validates: Requirements 15.7**
|
||||
|
||||
### Property 10: Exponentially Weighted Momentum Direction
|
||||
|
||||
*For any* sequence of monotonically increasing signed trend strengths (each ΔS_{t-k} > 0), the exponentially weighted momentum M_t SHALL be positive. Consistently strengthening bullish trends always produce positive momentum.
|
||||
|
||||
**Validates: Requirements 13.6, 17.6**
|
||||
|
||||
### Property 11: Competitive Signal Distance Attenuation
|
||||
|
||||
*For any* source-target company pair with fixed source signal strength S_source and historical correlation ρ_historical, the transfer strength S_transfer SHALL decrease monotonically with increasing graph distance d_network. Closer competitors always receive stronger signal transfer.
|
||||
|
||||
**Validates: Requirements 12.7**
|
||||
|
||||
### Property 12: Expected Value Directional Consistency
|
||||
|
||||
*For any* Bayesian bullish probability P_bull > 0.5 and estimated returns where R_up > R_down, the expected value EV = P_bull · R_up - (1 - P_bull) · R_down SHALL be positive. When the model is bullish and upside exceeds downside, EV is always positive.
|
||||
|
||||
**Validates: Requirements 17.8**
|
||||
|
||||
### Property 13: Bayesian Confidence Monotonic with Agreeing Signals
|
||||
|
||||
*For any* set of weighted signals where all signals agree on direction (all positive or all negative), adding one more agreeing signal SHALL increase the Bayesian confidence C. More agreeing evidence always increases confidence.
|
||||
|
||||
**Validates: Requirements 8.6**
|
||||
|
||||
### Property 14: Numerical Stability Across All Formulas
|
||||
|
||||
*For any* valid input combination to any formula in the probabilistic pipeline (sigmoid gate, Beta posterior, Bayesian confidence, adaptive decay, regime multiplier, Shannon entropy, multiplicative exposure, EW momentum, expected value), the output SHALL be a finite float (not NaN, not infinity) within the documented range for that formula. This includes regime multiplier M_regime ∈ [1.0, 2.5], entropy H ∈ [0, 1], P_bull ∈ [0, 1], confidence ∈ [0, 1], and M_adj ∈ [-2.0, 2.0].
|
||||
|
||||
**Validates: Requirements 17.9, 6.4**
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Numerical Edge Cases
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| P_bull = 0.0 or 1.0 (entropy undefined) | Return H = 0.0 (no uncertainty at extremes) |
|
||||
| σ_20 = 0.0 (zero volatility for momentum scaling) | Use floor max(σ_20, 0.01) per Req 13.4 |
|
||||
| σ_20 = 0.0 or σ_100 = 0.0 (volatility ratio) | Default to uncertainty regime |
|
||||
| log₂(0) in entropy computation | Guard with `if p <= 0 or p >= 1: return 0.0` |
|
||||
| log₂(0) in information gain (base_rate = 0) | Base rates must be > 0; use default 0.1 for unknown |
|
||||
| Division by zero in z-score (σ = 0) | Use M_regime = 1.0 when σ = 0 |
|
||||
| Empty signal list | Return uninformative prior (P_bull=0.5, α=1, β=1, C=0) |
|
||||
| All neutral signals (no positive or negative) | Contradiction = 0.0, direction = neutral |
|
||||
| Extremely large weights (overflow risk) | Python floats handle up to ~1.8e308; clamp combined weight if needed |
|
||||
| NaN from upstream data | Validate inputs; skip signals with NaN weight or sentiment |
|
||||
|
||||
### Feature Flag Failure Modes
|
||||
|
||||
| Failure | Behavior |
|
||||
|---------|----------|
|
||||
| `risk_configs` table unreachable | Default to `probabilistic_scoring_enabled = false` (heuristic mode) |
|
||||
| `config` JSONB missing the key | Default to `false` |
|
||||
| Invalid value type for flag | Default to `false`, log warning |
|
||||
| Flag changes mid-cycle | Flag is read once at cycle start; change takes effect next cycle |
|
||||
|
||||
### Source Accuracy Failures
|
||||
|
||||
| Failure | Behavior |
|
||||
|---------|----------|
|
||||
| `source_accuracy` table unreachable | Use neutral factor 1.0 for all sources |
|
||||
| Accuracy update fails | Log error, continue with stale accuracy data |
|
||||
| Corrupted accuracy data (ratio > 1.0 or < 0.0) | Clamp to [0.0, 1.0] |
|
||||
|
||||
### Regime Detection Failures
|
||||
|
||||
| Failure | Behavior |
|
||||
|---------|----------|
|
||||
| Market data unavailable | Default to uncertainty regime with default thresholds |
|
||||
| Insufficient price history (< 100 days) | Default to uncertainty regime |
|
||||
| Price data contains gaps | Use available data; EMA computation handles gaps gracefully |
|
||||
|
||||
---
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Dual Testing Approach
|
||||
|
||||
The signal math upgrade requires both property-based tests (for mathematical correctness) and example-based unit tests (for specific behaviors and integration points). Property-based testing is highly appropriate here because the feature consists primarily of pure mathematical functions with clear input/output behavior, universal properties that hold across wide input spaces, and well-defined range invariants.
|
||||
|
||||
### Property-Based Testing
|
||||
|
||||
**Library:** Hypothesis (already in use per `.hypothesis/` directory and project conventions)
|
||||
|
||||
**Configuration:**
|
||||
- Minimum 100 iterations per property: `@settings(max_examples=100)`
|
||||
- File naming: `test_pbt_signal_math.py` (or split by module)
|
||||
- Tag format: `# Feature: signal-math-upgrade, Property N: <title>`
|
||||
|
||||
**Property tests to implement (one test per correctness property):**
|
||||
|
||||
| Property | Test File | Key Generators |
|
||||
|----------|-----------|----------------|
|
||||
| 1: Sigmoid monotonicity | `test_pbt_signal_math.py` | `st.floats(0.0, 1.0)` pairs |
|
||||
| 2: Evidence accumulation | `test_pbt_signal_math.py` | `st.lists(weighted_signal_strategy)` |
|
||||
| 3: Confidence symmetry/divergence | `test_pbt_signal_math.py` | `st.floats(1.0, 100.0)` for α, β |
|
||||
| 4: Posterior round-trip | `test_pbt_signal_math.py` | `st.lists(uniform_weight_signal_strategy)` |
|
||||
| 5: Adaptive decay lower bound | `test_pbt_signal_math.py` | `st.floats` for impact, surprise, market |
|
||||
| 6: Info gain monotonicity | `test_pbt_signal_math.py` | `st.floats(0.001, 1.0)` pairs |
|
||||
| 7: Macro exposure monotonicity | `test_pbt_signal_math.py` | `st.floats(0.0, 1.0)` for overlaps |
|
||||
| 8: Entropy range/maximum | `test_pbt_signal_math.py` | `st.floats(0.001, 0.999)` for P_bull |
|
||||
| 9: Contradiction monotonicity | `test_pbt_signal_math.py` | Signal sets with varying weight splits |
|
||||
| 10: EW momentum direction | `test_pbt_signal_math.py` | `st.lists(st.floats)` monotonic sequences |
|
||||
| 11: Distance attenuation | `test_pbt_signal_math.py` | `st.integers(1, 3)` for distance |
|
||||
| 12: EV directional consistency | `test_pbt_signal_math.py` | `st.floats(0.5, 1.0)` for P_bull |
|
||||
| 13: Confidence with agreeing signals | `test_pbt_signal_math.py` | Growing lists of same-direction signals |
|
||||
| 14: Numerical stability | `test_pbt_signal_math.py` | Broad `st.floats` for all formula inputs |
|
||||
|
||||
### Example-Based Unit Tests
|
||||
|
||||
**File:** `test_signal_math_unit.py`
|
||||
|
||||
| Test Area | Examples |
|
||||
|-----------|----------|
|
||||
| Sigmoid gate specific values | x=0.5→0.5, x=0.2→<0.05, x=0.8→>0.95 |
|
||||
| Uninformative prior | Empty signals → P_bull=0.5, α=1, β=1, C=0 |
|
||||
| Default base rate | Unknown event type → base_rate=0.1 |
|
||||
| Info gain clamp | Very rare event → factor ≤ 3.0 |
|
||||
| Source accuracy threshold | sample_count < 10 → factor=1.0 |
|
||||
| Adaptive decay edge cases | All zeros → τ_base, all max → 6×τ_base |
|
||||
| Regime classification | Specific (R, V_r) → expected regime |
|
||||
| Regime thresholds | panic→0.10, mean_reversion→0.20, etc. |
|
||||
| Entropy direction mapping | H>0.9→mixed, P_bull>0.65→bullish, etc. |
|
||||
| Zero overlap → zero impact | All overlaps zero → S_macro=0 |
|
||||
| Max overlap value | All overlaps 1.0 → ≈severity×0.724 |
|
||||
| Macro fallback behaviors | Only macro → additive, only company → no modifier |
|
||||
| Graph distance cutoff | d>3 → no propagation |
|
||||
| Momentum fallback | <2 cycles → heuristic fallback |
|
||||
| EV threshold behavior | EV>0.005→proceed, EV≤0.005→informational |
|
||||
| Feature flag behaviors | flag=false→heuristic, flag=true→probabilistic |
|
||||
| Heuristic equivalence | flag=false produces identical outputs to current system |
|
||||
|
||||
### Integration Tests
|
||||
|
||||
| Test Area | Scope |
|
||||
|-----------|-------|
|
||||
| Source accuracy persistence | Write/read from source_accuracy table |
|
||||
| Regime persistence | Store/retrieve regime in JSONB |
|
||||
| EV persistence | Store/retrieve EV in recommendation_evaluations |
|
||||
| Feature flag reading | Read probabilistic_scoring_enabled from risk_configs |
|
||||
| End-to-end pipeline | Full aggregation cycle with probabilistic=true |
|
||||
|
||||
### Test Organization
|
||||
|
||||
```
|
||||
tests/
|
||||
├── test_pbt_signal_math.py # All 14 property-based tests
|
||||
├── test_signal_math_unit.py # Example-based unit tests
|
||||
├── test_bayesian.py # Bayesian accumulator unit tests
|
||||
├── test_regime.py # Regime detector unit tests
|
||||
├── test_source_accuracy.py # Source accuracy tracker tests
|
||||
└── test_signal_math_integration.py # Integration tests (DB required)
|
||||
```
|
||||
@@ -0,0 +1,293 @@
|
||||
# Requirements Document — Signal Math Upgrade
|
||||
|
||||
## Introduction
|
||||
|
||||
The Stonks Oracle platform uses a three-layer signal aggregation engine (company-specific, macro, competitive) to produce market intelligence and drive paper-trading decisions. The current mathematical models are structurally too deterministic and too linear for a market system that is fundamentally probabilistic, regime-dependent, and nonlinear. The pipeline behaves as weighted sentiment aggregation with heuristics rather than a probabilistic forecasting engine.
|
||||
|
||||
This feature upgrades the signal processing mathematics across all pipeline stages — from signal scoring through trend assembly, macro impact, competitive signals, trend projection, and recommendation generation — to replace heuristic formulas with probabilistic, regime-aware, and adaptive alternatives. The goal is to transform prediction quality while preserving the existing `WeightedSignal` abstraction, three-layer architecture, and database schema compatibility.
|
||||
|
||||
## Glossary
|
||||
|
||||
- **Aggregation_Engine**: The core pipeline in `services/aggregation/worker.py` that merges signals from all three layers and computes `TrendSummary` objects across five time windows.
|
||||
- **Signal_Scorer**: The scoring module in `services/aggregation/scoring.py` that transforms raw intelligence records into `WeightedSignal` objects with composite aggregation weights.
|
||||
- **Trend_Assembler**: The component in `services/aggregation/worker.py` that derives trend direction, strength, confidence, and contradiction from merged weighted signals.
|
||||
- **Macro_Scorer**: The macro impact scoring module in `services/aggregation/interpolation.py` that computes per-company impact from global events using overlap-based exposure profiles.
|
||||
- **Competitive_Scorer**: The competitive signal modules in `services/aggregation/pattern_matcher.py` and `services/aggregation/signal_propagation.py` that mine historical patterns and propagate cross-company signals.
|
||||
- **Projection_Engine**: The trend projection module in `services/aggregation/projection.py` that computes forward-looking trend estimates from momentum and macro decay.
|
||||
- **Recommendation_Engine**: The recommendation pipeline in `services/recommendation/` that translates trend assessments into actionable buy/sell/hold/watch decisions with position sizing.
|
||||
- **WeightedSignal**: The core data abstraction pairing a document reference with a composite aggregation weight, sentiment value, and impact score.
|
||||
- **Beta_Distribution**: A probability distribution on [0, 1] parameterized by α and β, used to model the posterior probability of bullish vs bearish sentiment.
|
||||
- **Regime_Detector**: A new component that classifies the current market regime (trend-following, panic, mean-reversion, uncertainty) from price and volume statistics.
|
||||
- **Sigmoid_Function**: The logistic function σ(x) = 1/(1+e^(-x)) used to convert log-likelihood accumulations into probabilities.
|
||||
- **Adaptive_Decay**: A recency decay mechanism where the half-life varies per signal based on event impact, surprise, and market reaction rather than using a fixed constant per window.
|
||||
- **Information_Gain**: A measure of how surprising an event is relative to its base rate, computed as -log P(event_type), used to weight novel signals more heavily.
|
||||
- **Entropy**: Shannon entropy H = -p·log(p) - (1-p)·log(1-p), used to detect mixed sentiment states where the probability distribution is spread rather than concentrated.
|
||||
- **EMA**: Exponential Moving Average, a weighted moving average giving more weight to recent observations, used for trend and volatility regime detection.
|
||||
|
||||
---
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement 1: Probabilistic Sentiment Accumulation via Bayesian Evidence
|
||||
|
||||
**User Story:** As a quantitative analyst, I want the signal scoring layer to accumulate sentiment evidence probabilistically using Bayesian methods, so that the system captures uncertainty structure instead of collapsing sentiment into binary ±1 labels.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN a set of weighted signals is provided for a ticker and window, THE Signal_Scorer SHALL compute a log-likelihood accumulation L_t = Σ(w_i · s_i) where w_i is the combined signal weight and s_i is the sentiment value.
|
||||
2. WHEN the log-likelihood L_t has been computed, THE Signal_Scorer SHALL convert the accumulation to a bullish probability using the Sigmoid_Function: P_bull = σ(L_t) = 1/(1+e^(-L_t)).
|
||||
3. WHEN weighted signals are provided, THE Signal_Scorer SHALL maintain a Beta_Distribution posterior with parameters α_t = α_0 + W_bull and β_t = β_0 + W_bear, where W_bull is the sum of combined weights for positive signals and W_bear is the sum for negative signals, and α_0 = β_0 = 1.0 as uninformative priors.
|
||||
4. THE Signal_Scorer SHALL compute Bayesian confidence from the Beta_Distribution posterior variance as C = 1 - 4αβ/(α+β)², where C ranges from 0.0 (maximum uncertainty at α=β) to approaching 1.0 (strong evidence concentration).
|
||||
5. WHEN no signals exist for a ticker and window, THE Signal_Scorer SHALL return P_bull = 0.5, α = 1.0, β = 1.0, and C = 0.0, representing the uninformative prior state.
|
||||
6. THE Signal_Scorer SHALL preserve the existing `WeightedSignal` dataclass interface, adding the Bayesian posterior fields (P_bull, α, β, Bayesian confidence) as additional output alongside the existing weighted sentiment average.
|
||||
7. FOR ALL valid sets of weighted signals, computing the Beta posterior then extracting P_bull SHALL produce a value within 0.05 of σ(L_t) when signal weights are uniform (round-trip consistency between the two probabilistic representations).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 2: Sigmoid Confidence Gate Replacing Binary Gate
|
||||
|
||||
**User Story:** As a quantitative analyst, I want the binary confidence gate replaced with a smooth sigmoid transition, so that marginally confident signals contribute proportionally rather than being completely discarded or fully included.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN a document signal has extraction confidence x, THE Signal_Scorer SHALL compute a soft gate value p = σ(5·(x - 0.5)) = 1/(1+e^(-5·(x-0.5))) instead of the current binary 0/1 gate.
|
||||
2. WHEN extraction confidence is 0.5, THE Signal_Scorer SHALL produce a gate value of 0.5 (the sigmoid midpoint).
|
||||
3. WHEN extraction confidence is below 0.2, THE Signal_Scorer SHALL produce a gate value below 0.05, preserving near-zero weight for very low confidence signals.
|
||||
4. WHEN extraction confidence is above 0.8, THE Signal_Scorer SHALL produce a gate value above 0.95, preserving near-full weight for high confidence signals.
|
||||
5. THE Signal_Scorer SHALL use the sigmoid gate value as a multiplicative factor in the combined weight formula in place of the current binary G_conf.
|
||||
6. FOR ALL extraction confidence values in [0.0, 1.0], THE Signal_Scorer SHALL produce gate values that are monotonically increasing (higher confidence always produces equal or higher gate values).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 3: Information Gain Surprise Weighting
|
||||
|
||||
**User Story:** As a quantitative analyst, I want signals weighted by their information gain (surprise factor), so that rare and unexpected events receive proportionally higher influence than routine signals.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN a signal has a known event type (e.g., earnings, product_launch, regulatory, legal, m_and_a), THE Signal_Scorer SHALL compute an information gain factor r = 1 + λ·(-log₂ P(event_type)), where P(event_type) is the empirical base rate of that event type and λ is a configurable scaling parameter with default 0.3.
|
||||
2. WHEN the event type base rate is not available, THE Signal_Scorer SHALL use a default base rate of 0.1 (treating the event as moderately rare).
|
||||
3. THE Signal_Scorer SHALL multiply the information gain factor r into the combined weight formula as an additional multiplicative component.
|
||||
4. THE Signal_Scorer SHALL clamp the information gain factor to a maximum of 3.0 to prevent extremely rare events from dominating the aggregation.
|
||||
5. FOR ALL event types with base rate in (0, 1], THE Signal_Scorer SHALL produce information gain factors that are monotonically decreasing with increasing base rate (rarer events always receive higher surprise weight).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 4: Historical Source Accuracy Tracking
|
||||
|
||||
**User Story:** As a quantitative analyst, I want source credibility to incorporate historical prediction accuracy, so that sources with a track record of correct directional calls receive higher weight.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Signal_Scorer SHALL maintain a per-source accuracy metric computed as the fraction of past signals from that source where the predicted direction matched the subsequent 7-day price movement direction.
|
||||
2. WHEN a source has at least 10 historical signals with known outcomes, THE Signal_Scorer SHALL incorporate the source accuracy as a multiplicative factor on the credibility weight, scaled linearly from 0.5 (0% accuracy) to 1.5 (100% accuracy).
|
||||
3. WHEN a source has fewer than 10 historical signals, THE Signal_Scorer SHALL use a neutral accuracy factor of 1.0 (no adjustment).
|
||||
4. THE Signal_Scorer SHALL update source accuracy metrics asynchronously after each aggregation cycle, using realized price data from the market data tables.
|
||||
5. THE Signal_Scorer SHALL store source accuracy metrics in a database table with columns for source identifier, accuracy ratio, sample count, and last updated timestamp.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 5: Adaptive Recency Decay with Event-Specific Half-Lives
|
||||
|
||||
**User Story:** As a quantitative analyst, I want recency decay half-lives to adapt based on event characteristics, so that high-impact events persist longer in the aggregation while routine signals decay faster.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN computing recency decay for a signal, THE Signal_Scorer SHALL use an adaptive half-life τ_i = τ_base · (1 + β_impact) · (1 + β_surprise) · (1 + β_market_reaction), where τ_base is the current fixed half-life for the window.
|
||||
2. THE Signal_Scorer SHALL compute β_impact from the signal's impact score, scaled linearly from 0.0 (impact_score = 0) to 1.0 (impact_score = 1.0).
|
||||
3. THE Signal_Scorer SHALL compute β_surprise from the information gain factor (Requirement 3), scaled linearly from 0.0 (r = 1.0, no surprise) to 1.0 (r = 3.0, maximum surprise).
|
||||
4. THE Signal_Scorer SHALL compute β_market_reaction from the market context multiplier, scaled linearly from 0.0 (multiplier = 1.0, no market reaction) to 0.5 (multiplier = 1.45, maximum market reaction).
|
||||
5. WHEN all three β factors are at their maximum, THE Signal_Scorer SHALL produce an adaptive half-life of at most 6× the base half-life (τ_base · 2.0 · 2.0 · 1.5 = 6.0 · τ_base).
|
||||
6. WHEN all three β factors are zero (routine, unsurprising signal in calm market), THE Signal_Scorer SHALL produce the same half-life as the current fixed system (τ_base).
|
||||
7. FOR ALL combinations of impact, surprise, and market reaction values, THE Signal_Scorer SHALL produce adaptive half-lives that are greater than or equal to τ_base (adaptive decay is always slower or equal to the base decay, never faster).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 6: Volatility-Adjusted Normalization (Regime-Aware Scoring)
|
||||
|
||||
**User Story:** As a quantitative analyst, I want signal weights normalized by current market volatility and volume conditions, so that the same signal magnitude is interpreted differently in calm vs volatile markets.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN market data is available for a ticker, THE Signal_Scorer SHALL compute a return z-score z_r = (r_t - μ_20) / σ_20, where r_t is the current return, μ_20 is the 20-day mean return, and σ_20 is the 20-day return standard deviation.
|
||||
2. WHEN market data is available for a ticker, THE Signal_Scorer SHALL compute a volume z-score z_v = (log(V_t) - μ_V) / σ_V, where V_t is the current volume, μ_V is the 20-day mean of log-volume, and σ_V is the 20-day standard deviation of log-volume.
|
||||
3. THE Signal_Scorer SHALL compute a regime multiplier M_regime = 1 + 0.15·|z_r| + 0.10·|z_v|, which amplifies signal weights during abnormal market conditions.
|
||||
4. THE Signal_Scorer SHALL clamp M_regime to the range [1.0, 2.5] to prevent extreme z-scores from producing runaway weight amplification.
|
||||
5. WHEN market data is not available for a ticker, THE Signal_Scorer SHALL use M_regime = 1.0 (no regime adjustment).
|
||||
6. THE Signal_Scorer SHALL replace the current market context multiplier (M_context) with M_regime in the combined weight formula.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 7: Regime Detection and Classification
|
||||
|
||||
**User Story:** As a quantitative analyst, I want the system to detect and classify the current market regime for each ticker, so that scoring thresholds and behavior adapt to whether the market is trending, panicking, mean-reverting, or uncertain.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN market data is available, THE Regime_Detector SHALL compute a trend indicator R = sign(EMA_20 - EMA_100), where EMA_20 and EMA_100 are exponential moving averages of closing prices over 20 and 100 days respectively.
|
||||
2. WHEN market data is available, THE Regime_Detector SHALL compute a volatility ratio V_r = σ_20 / σ_100, where σ_20 and σ_100 are the 20-day and 100-day return standard deviations.
|
||||
3. THE Regime_Detector SHALL classify the market regime into one of four categories based on R and V_r: trend-following (R ≠ 0 AND V_r < 1.2), panic (V_r > 1.5), mean-reversion (R = 0 AND V_r < 1.0), uncertainty (all other cases).
|
||||
4. WHEN the regime is classified as panic, THE Aggregation_Engine SHALL reduce the bullish/bearish threshold from ±0.15 to ±0.10 (making the system more sensitive to directional signals during high-volatility periods).
|
||||
5. WHEN the regime is classified as mean-reversion, THE Aggregation_Engine SHALL increase the bullish/bearish threshold from ±0.15 to ±0.20 (requiring stronger evidence for directional calls in range-bound markets).
|
||||
6. WHEN the regime is classified as trend-following, THE Aggregation_Engine SHALL use the default thresholds of ±0.15.
|
||||
7. WHEN the regime is classified as uncertainty, THE Aggregation_Engine SHALL use the default thresholds of ±0.15 and increase the contradiction penalty multiplier from 0.4 to 0.6.
|
||||
8. THE Regime_Detector SHALL persist the current regime classification per ticker to the database for auditability and dashboard display.
|
||||
9. WHEN market data is insufficient to compute EMA_100 (fewer than 100 days of price history), THE Regime_Detector SHALL default to the uncertainty regime.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 8: Bayesian Posterior Confidence Replacing Heuristic Confidence
|
||||
|
||||
**User Story:** As a quantitative analyst, I want trend confidence derived from the Bayesian posterior distribution rather than the current heuristic weighted formula, so that confidence reflects actual evidence concentration rather than an ad-hoc combination of factors.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN computing trend confidence, THE Trend_Assembler SHALL use the Bayesian confidence C = 1 - 4αβ/(α+β)² from the Beta_Distribution posterior (Requirement 1) as the primary confidence component with weight 0.5.
|
||||
2. THE Trend_Assembler SHALL retain the source count factor (min(N_unique/15, 0.8)) as a secondary confidence component with weight 0.25, rewarding evidence breadth.
|
||||
3. THE Trend_Assembler SHALL retain the contradiction penalty (contradiction_score × 0.4) as a confidence reduction.
|
||||
4. THE Trend_Assembler SHALL compute the combined confidence as: confidence = 0.5 × C_bayesian + 0.25 × F_count + 0.25 × C_avg_credibility - P_contradiction, clamped to [0.0, 1.0].
|
||||
5. THE Trend_Assembler SHALL preserve the existing confidence thresholds for recommendation eligibility (0.35 minimum, 0.50 paper, 0.70 live) without modification.
|
||||
6. FOR ALL signal sets where all signals agree on direction, THE Trend_Assembler SHALL produce Bayesian confidence that increases monotonically with the number of agreeing signals.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 9: Entropy-Based Mixed Signal Detection
|
||||
|
||||
**User Story:** As a quantitative analyst, I want mixed trend detection based on Shannon entropy rather than simple contradiction thresholds, so that the system can distinguish between genuine uncertainty (high entropy) and weak signal (low total weight).
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN the bullish probability P_bull has been computed from the Bayesian posterior, THE Trend_Assembler SHALL compute Shannon entropy H = -P_bull·log₂(P_bull) - (1-P_bull)·log₂(1-P_bull).
|
||||
2. WHEN H > 0.9 (entropy close to maximum of 1.0, indicating near-equal probability of bullish and bearish), THE Trend_Assembler SHALL classify the trend direction as mixed, regardless of the weighted sentiment average.
|
||||
3. WHEN H ≤ 0.9 AND P_bull > 0.65, THE Trend_Assembler SHALL classify the trend direction as bullish.
|
||||
4. WHEN H ≤ 0.9 AND P_bull < 0.35, THE Trend_Assembler SHALL classify the trend direction as bearish.
|
||||
5. WHEN H ≤ 0.9 AND 0.35 ≤ P_bull ≤ 0.65, THE Trend_Assembler SHALL classify the trend direction as neutral.
|
||||
6. THE Trend_Assembler SHALL persist the entropy value H alongside the trend summary for auditability.
|
||||
7. FOR ALL P_bull values in (0, 1), THE Trend_Assembler SHALL compute entropy values in (0, 1], with maximum entropy of 1.0 occurring at P_bull = 0.5.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 10: Multiplicative Macro Exposure Scoring
|
||||
|
||||
**User Story:** As a quantitative analyst, I want macro impact computed using multiplicative exposure rather than linear weighted sums, so that a company exposed across multiple dimensions receives compounding impact rather than simple addition.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN computing macro impact for a company, THE Macro_Scorer SHALL use the multiplicative exposure formula S_macro = severity · (1 - Π_k(1 - w_k · O_k)), where O_k are the overlap components (geographic, supply chain, commodity, sector) and w_k are their respective weights.
|
||||
2. THE Macro_Scorer SHALL use the following overlap weights: w_geo = 0.35, w_supply = 0.25, w_commodity = 0.25, w_sector = 0.15 (matching the current linear weight distribution).
|
||||
3. WHEN a company has zero overlap across all dimensions, THE Macro_Scorer SHALL produce S_macro = 0.0 (no impact).
|
||||
4. WHEN a company has maximum overlap across all dimensions (all O_k = 1.0), THE Macro_Scorer SHALL produce S_macro = severity · (1 - (1-0.35)·(1-0.25)·(1-0.25)·(1-0.15)), which is approximately severity · 0.724.
|
||||
5. THE Macro_Scorer SHALL preserve the existing severity weight mapping (critical=1.0, high=0.75, moderate=0.5, low=0.25).
|
||||
6. THE Macro_Scorer SHALL preserve the existing resilience modifier (R_tier) applied after the multiplicative exposure computation.
|
||||
7. FOR ALL overlap configurations, THE Macro_Scorer SHALL produce impact scores where adding a non-zero overlap in any dimension increases the total impact (monotonicity property).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 11: Conditional Macro Signal Integration
|
||||
|
||||
**User Story:** As a quantitative analyst, I want macro signals treated as conditional modifiers on company signals rather than additive contributions, so that macro context amplifies or dampens existing company-level evidence rather than independently shifting the trend.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN both company signals and macro signals exist for a ticker, THE Aggregation_Engine SHALL apply macro impact as a multiplicative modifier on the company signal strength: S_adjusted = S_company · (1 + M_macro · sign_alignment), where M_macro is the normalized macro impact and sign_alignment is +1 when macro and company signals agree in direction, -1 when they disagree.
|
||||
2. THE Aggregation_Engine SHALL clamp the macro modifier (1 + M_macro · sign_alignment) to the range [0.5, 1.5] to prevent macro signals from inverting or excessively amplifying company signals.
|
||||
3. WHEN only macro signals exist (no company signals), THE Aggregation_Engine SHALL fall back to the current additive behavior with the existing macro weight of 0.3, preserving the macro-only suppression safety mechanism.
|
||||
4. WHEN only company signals exist (macro layer disabled or no macro events), THE Aggregation_Engine SHALL use company signals without modification (modifier = 1.0).
|
||||
5. THE Aggregation_Engine SHALL log the macro modifier value applied to each ticker for auditability.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 12: Graph-Distance Competitive Signal Attenuation
|
||||
|
||||
**User Story:** As a quantitative analyst, I want competitive signal transfer attenuated by network graph distance and historical correlation, so that signals propagate more strongly to closely related competitors and decay for distant relationships.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN propagating a signal from a source company to a target company, THE Competitive_Scorer SHALL compute transfer strength as S_transfer = S_source · ρ_historical · e^(-d_network), where S_source is the source signal strength, ρ_historical is the historical price correlation between the two companies, and d_network is the graph distance in the competitor relationship network.
|
||||
2. THE Competitive_Scorer SHALL compute graph distance d_network as the shortest path length in the competitor relationship graph, where direct competitors have distance 1, competitors-of-competitors have distance 2, and so on.
|
||||
3. WHEN the graph distance exceeds 3, THE Competitive_Scorer SHALL not propagate the signal (e^(-3) ≈ 0.05, below meaningful contribution).
|
||||
4. THE Competitive_Scorer SHALL compute ρ_historical as the 90-day rolling Pearson correlation of daily returns between the source and target companies.
|
||||
5. WHEN historical correlation data is insufficient (fewer than 30 trading days of overlapping data), THE Competitive_Scorer SHALL use a default correlation of 0.3 for same-sector companies and 0.1 for cross-sector companies.
|
||||
6. THE Competitive_Scorer SHALL preserve the existing relationship strength threshold (R_relationship ≥ 0.2) as a pre-filter before applying the graph-distance attenuation.
|
||||
7. FOR ALL source-target pairs, THE Competitive_Scorer SHALL produce transfer strengths that decrease monotonically with increasing graph distance (closer competitors always receive stronger signal transfer).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 13: Exponentially Weighted Momentum
|
||||
|
||||
**User Story:** As a quantitative analyst, I want trend momentum computed using exponentially weighted historical changes rather than a simple current-minus-previous difference, so that the momentum estimate is smoother and less sensitive to single-cycle noise.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN computing trend momentum, THE Projection_Engine SHALL use an exponentially weighted sum M_t = Σ_{k=0}^{K-1} λ^k · ΔS_{t-k}, where ΔS_{t-k} is the signed strength change at lag k, λ = 0.7 is the decay factor, and K is the number of available historical cycles (up to 10).
|
||||
2. THE Projection_Engine SHALL normalize the momentum by dividing by the geometric series sum Σ λ^k to produce a value in [-1, 1].
|
||||
3. WHEN fewer than 2 historical cycles are available, THE Projection_Engine SHALL fall back to the current heuristic (momentum = direction_sign × strength × 0.5).
|
||||
4. THE Projection_Engine SHALL compute volatility-scaled momentum M_adj = M_t / max(σ_20, 0.01), where σ_20 is the 20-day return standard deviation, to normalize momentum relative to the ticker's typical price movement.
|
||||
5. THE Projection_Engine SHALL clamp M_adj to [-2.0, 2.0] to prevent division by very small σ_20 from producing extreme values.
|
||||
6. FOR ALL sequences of monotonically increasing signed strengths, THE Projection_Engine SHALL produce positive momentum values (correctly detecting strengthening bullish trends).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 14: Expected Value Recommendation Gate
|
||||
|
||||
**User Story:** As a quantitative analyst, I want recommendation eligibility based on expected value rather than simple confidence and strength thresholds, so that the system only recommends trades with positive risk-adjusted expected outcomes.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN evaluating recommendation eligibility, THE Recommendation_Engine SHALL compute expected value EV = P_bull · R_up - P_bear · R_down, where P_bull is the Bayesian bullish probability, P_bear = 1 - P_bull, R_up is the estimated upside return, and R_down is the estimated downside return.
|
||||
2. THE Recommendation_Engine SHALL estimate R_up and R_down from the trend strength and the ticker's 20-day historical volatility: R_up = strength · σ_20 · √(horizon_days) and R_down = (1 - strength) · σ_20 · √(horizon_days), where horizon_days corresponds to the trend window duration.
|
||||
3. WHEN EV is positive and exceeds a configurable threshold (default 0.005, representing 0.5% expected return), THE Recommendation_Engine SHALL allow the recommendation to proceed through the existing eligibility gates.
|
||||
4. WHEN EV is negative or below the threshold, THE Recommendation_Engine SHALL force the recommendation to informational mode regardless of confidence and strength.
|
||||
5. THE Recommendation_Engine SHALL persist the computed EV alongside the recommendation for auditability.
|
||||
6. THE Recommendation_Engine SHALL preserve all existing eligibility gates (confidence ≥ 0.35, strength ≥ 0.10, contradiction ≤ 0.60, evidence ≥ 2, direction ≠ neutral) as additional requirements beyond the EV gate.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 15: Contradiction Handling via Weighted Disagreement Entropy
|
||||
|
||||
**User Story:** As a quantitative analyst, I want contradiction detection to use weighted disagreement entropy rather than a simple minority/majority ratio, so that the system better distinguishes between a few strong dissenting signals and many weak ones.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN computing contradiction, THE Trend_Assembler SHALL compute weighted disagreement entropy using the effective weight distribution across positive and negative signal groups.
|
||||
2. THE Trend_Assembler SHALL compute the positive weight fraction f_pos = W_positive / (W_positive + W_negative) and negative weight fraction f_neg = W_negative / (W_positive + W_negative), where W_positive and W_negative are the sums of effective weights (combined_weight × impact_score) for each sentiment group.
|
||||
3. THE Trend_Assembler SHALL compute contradiction entropy as H_contradiction = -f_pos·log₂(f_pos) - f_neg·log₂(f_neg), normalized to [0, 1] (maximum at f_pos = f_neg = 0.5).
|
||||
4. THE Trend_Assembler SHALL weight the contradiction entropy by the total evidence mass: contradiction_score = H_contradiction · min(1.0, (W_positive + W_negative) / W_threshold), where W_threshold is a configurable parameter (default 5.0) representing the evidence mass at which contradiction becomes fully significant.
|
||||
5. WHEN only positive or only negative signals exist (no disagreement), THE Trend_Assembler SHALL produce a contradiction score of 0.0.
|
||||
6. THE Trend_Assembler SHALL preserve the existing `ContradictionResult` interface, populating the overall score with the entropy-based value and retaining the `DisagreementDetail` objects for catalyst-level analysis.
|
||||
7. FOR ALL signal sets with both positive and negative signals, THE Trend_Assembler SHALL produce contradiction scores that increase monotonically as the weight distribution approaches equal split (f_pos → 0.5).
|
||||
|
||||
---
|
||||
|
||||
### Requirement 16: Backward Compatibility and Migration
|
||||
|
||||
**User Story:** As a platform operator, I want the mathematical upgrades to be backward-compatible with the existing database schema and deployable incrementally, so that the upgrade does not require downtime or data migration.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Aggregation_Engine SHALL preserve the existing `WeightedSignal`, `SignalWeight`, `TrendSummary`, and `Recommendation` dataclass interfaces, adding new fields as optional attributes with default values.
|
||||
2. THE Aggregation_Engine SHALL store new mathematical outputs (P_bull, α, β, entropy, regime, EV) in the existing JSONB metadata fields of `trend_windows` and `recommendations` tables rather than requiring new columns.
|
||||
3. THE Aggregation_Engine SHALL support a feature flag `probabilistic_scoring_enabled` in `risk_configs` that toggles between the current heuristic pipeline and the new probabilistic pipeline, defaultable to `false` for safe rollout.
|
||||
4. WHEN `probabilistic_scoring_enabled` is false, THE Aggregation_Engine SHALL produce identical outputs to the current system (no behavioral change).
|
||||
5. WHEN `probabilistic_scoring_enabled` is true, THE Aggregation_Engine SHALL use the new Bayesian, regime-aware, and adaptive formulas for all pipeline stages.
|
||||
6. IF the feature flag toggle fails to read from the database, THEN THE Aggregation_Engine SHALL default to the current heuristic pipeline (fail-safe behavior).
|
||||
7. THE Aggregation_Engine SHALL log which pipeline mode (heuristic or probabilistic) is active at the start of each aggregation cycle.
|
||||
|
||||
---
|
||||
|
||||
### Requirement 17: Property-Based Testing for Mathematical Correctness
|
||||
|
||||
**User Story:** As a developer, I want comprehensive property-based tests validating the mathematical correctness of all new formulas, so that edge cases and numerical stability issues are caught before deployment.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE test suite SHALL include property-based tests using Hypothesis for the sigmoid confidence gate verifying monotonicity (higher confidence input always produces higher or equal gate output) across all float inputs in [0.0, 1.0].
|
||||
2. THE test suite SHALL include property-based tests for the Beta_Distribution posterior verifying that α + β increases monotonically with the number of signals processed (evidence always accumulates).
|
||||
3. THE test suite SHALL include property-based tests for the Bayesian confidence formula verifying that confidence is 0.0 when α = β (maximum uncertainty) and approaches 1.0 as the ratio α/β or β/α increases.
|
||||
4. THE test suite SHALL include property-based tests for the adaptive decay verifying that the adaptive half-life is always greater than or equal to the base half-life for all valid input combinations.
|
||||
5. THE test suite SHALL include property-based tests for the multiplicative macro exposure verifying monotonicity (adding non-zero overlap in any dimension increases total impact).
|
||||
6. THE test suite SHALL include property-based tests for the exponentially weighted momentum verifying that monotonically increasing strength sequences produce positive momentum.
|
||||
7. THE test suite SHALL include a round-trip property test verifying that computing the Beta posterior from signals, extracting P_bull, then reconstructing approximate signal weights produces values consistent with the original inputs.
|
||||
8. THE test suite SHALL include property-based tests for the expected value computation verifying that EV is positive when P_bull > 0.5 and R_up > R_down (basic directional consistency).
|
||||
9. THE test suite SHALL include property-based tests for numerical stability verifying that no formula produces NaN, infinity, or values outside documented ranges for any valid input combination.
|
||||
10. THE test suite SHALL use `@settings(max_examples=100)` and follow the project convention of `test_pbt_*` file naming.
|
||||
@@ -0,0 +1,349 @@
|
||||
# Implementation Plan: Signal Math Upgrade
|
||||
|
||||
## Overview
|
||||
|
||||
Upgrade the Stonks Oracle signal processing pipeline from deterministic heuristic formulas to a probabilistic, regime-aware, and adaptive mathematical framework. Implementation proceeds in layers: foundations (config, schemas, new modules), then each pipeline stage (scoring → trend assembly → macro → competitive → projection → recommendation), then integration wiring, and finally testing. All changes are gated behind the `probabilistic_scoring_enabled` feature flag.
|
||||
|
||||
## Tasks
|
||||
|
||||
- [ ] 1. Foundation: Configuration and schema extensions
|
||||
- [x] 1.1 Extend `ScoringConfig` with probabilistic parameters in `services/aggregation/scoring.py`
|
||||
- Add `probabilistic: bool = False` toggle field
|
||||
- Add sigmoid gate parameters: `sigmoid_steepness`, `sigmoid_midpoint`
|
||||
- Add information gain parameters: `info_gain_lambda`, `info_gain_max`, `default_base_rate`
|
||||
- Add adaptive decay parameters: `adaptive_decay_impact_scale`, `adaptive_decay_surprise_scale`, `adaptive_decay_market_scale`
|
||||
- Add regime multiplier parameters: `regime_return_weight`, `regime_volume_weight`, `regime_multiplier_max`
|
||||
- All new fields must have defaults matching the design document values
|
||||
- _Requirements: 2.5, 3.1, 5.1, 6.3, 16.1_
|
||||
|
||||
- [x] 1.2 Extend `SignalWeight` and `WeightedSignal` dataclasses in `services/aggregation/scoring.py`
|
||||
- Add optional fields to `SignalWeight`: `sigmoid_gate`, `info_gain_factor`, `source_accuracy_factor`, `regime_multiplier`
|
||||
- Add optional fields to `WeightedSignal`: `info_gain_factor`, `source_accuracy_factor`, `adaptive_half_life`
|
||||
- All new fields must have defaults (None or 1.0) for backward compatibility
|
||||
- _Requirements: 16.1, 2.5, 3.3, 4.2_
|
||||
|
||||
- [x] 1.3 Extend `TrendSummary` Pydantic model in `services/shared/schemas.py`
|
||||
- Add optional fields: `p_bull`, `alpha`, `beta_param`, `bayesian_confidence`, `entropy`, `regime`, `pipeline_mode`
|
||||
- `pipeline_mode` defaults to `"heuristic"`; all others default to `None`
|
||||
- _Requirements: 16.1, 1.6, 9.6_
|
||||
|
||||
- [x] 1.4 Extend `Recommendation` model in `services/shared/schemas.py` (or `services/recommendation/eligibility.py`)
|
||||
- Add optional fields: `expected_value`, `p_bull`, `pipeline_mode`
|
||||
- `pipeline_mode` defaults to `"heuristic"`; all others default to `None`
|
||||
- _Requirements: 16.1, 14.5_
|
||||
|
||||
- [x] 1.5 Add `probabilistic_scoring_enabled` feature flag support in `services/shared/config.py`
|
||||
- Read `probabilistic_scoring_enabled` from `risk_configs.config` JSONB
|
||||
- Default to `False` when key is missing, value is invalid, or DB is unreachable
|
||||
- Propagate flag through `AggregationConfig` dataclass
|
||||
- Log which pipeline mode is active at cycle start
|
||||
- _Requirements: 16.3, 16.4, 16.5, 16.6, 16.7_
|
||||
|
||||
- [x] 1.6 Create database migration `infra/migrations/034_source_accuracy.sql`
|
||||
- Create `source_accuracy` table with columns: `id UUID PRIMARY KEY DEFAULT gen_random_uuid()`, `source_id VARCHAR(200) NOT NULL`, `accuracy_ratio FLOAT NOT NULL DEFAULT 0.5`, `sample_count INTEGER NOT NULL DEFAULT 0`, `last_updated TIMESTAMPTZ`, `created_at TIMESTAMPTZ`
|
||||
- Add `UNIQUE(source_id)` constraint and `idx_source_accuracy_source` index
|
||||
- _Requirements: 4.5_
|
||||
|
||||
- [x] 2. Checkpoint — Verify foundation compiles and existing tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [ ] 3. New module: Bayesian Accumulator (`services/aggregation/bayesian.py`)
|
||||
- [x] 3.1 Implement `BayesianPosterior` dataclass and `compute_bayesian_posterior` function
|
||||
- Create frozen dataclass with fields: `p_bull`, `alpha`, `beta`, `log_likelihood`, `bayesian_confidence`, `entropy`, `signal_count`
|
||||
- Define `PRIOR` class-level constant for uninformative prior (p_bull=0.5, α=1.0, β=1.0, C=0.0, H=1.0)
|
||||
- Implement log-likelihood accumulation: `L_t = Σ(w_i · s_i)` using `weight.combined * sentiment_value`
|
||||
- Compute `P_bull = σ(L_t)` via sigmoid function
|
||||
- Compute Beta posterior: `α = 1 + W_bull`, `β = 1 + W_bear` from positive/negative weight sums
|
||||
- Compute Bayesian confidence: `C = 1 - 4αβ/(α+β)²`
|
||||
- Compute Shannon entropy via `compute_entropy`
|
||||
- Return `PRIOR` for empty signal lists
|
||||
- Skip signals with NaN weight or sentiment
|
||||
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5, 1.6_
|
||||
|
||||
- [x] 3.2 Implement `compute_entropy` function
|
||||
- Shannon entropy: `H = -p·log₂(p) - (1-p)·log₂(1-p)`
|
||||
- Return 0.0 for p ≤ 0 or p ≥ 1 (edge cases)
|
||||
- Return value in [0, 1] with maximum 1.0 at p=0.5
|
||||
- _Requirements: 9.1, 9.7_
|
||||
|
||||
- [x] 3.3 Write property test for sigmoid gate monotonicity
|
||||
- **Property 1: Sigmoid Gate Monotonicity**
|
||||
- **Validates: Requirements 2.6, 17.1**
|
||||
|
||||
- [x] 3.4 Write property test for Beta posterior evidence accumulation
|
||||
- **Property 2: Beta Posterior Evidence Accumulation**
|
||||
- **Validates: Requirements 1.3, 17.2**
|
||||
|
||||
- [x] 3.5 Write property test for Bayesian confidence symmetry and divergence
|
||||
- **Property 3: Bayesian Confidence Symmetry and Divergence**
|
||||
- **Validates: Requirements 1.4, 17.3**
|
||||
|
||||
- [x] 3.6 Write property test for Bayesian posterior round-trip consistency
|
||||
- **Property 4: Bayesian Posterior Round-Trip Consistency**
|
||||
- **Validates: Requirements 1.7, 17.7**
|
||||
|
||||
- [x] 3.7 Write property test for Shannon entropy range and maximum
|
||||
- **Property 8: Shannon Entropy Range and Maximum**
|
||||
- **Validates: Requirements 9.7**
|
||||
|
||||
- [x] 3.8 Write property test for Bayesian confidence monotonic with agreeing signals
|
||||
- **Property 13: Bayesian Confidence Monotonic with Agreeing Signals**
|
||||
- **Validates: Requirements 8.6**
|
||||
|
||||
- [ ] 4. New module: Regime Detector (`services/aggregation/regime.py`)
|
||||
- [x] 4.1 Implement `MarketRegime` enum, `RegimeClassification` and `RegimeConfig` dataclasses
|
||||
- `MarketRegime`: `TREND_FOLLOWING`, `PANIC`, `MEAN_REVERSION`, `UNCERTAINTY`
|
||||
- `RegimeClassification`: `regime`, `trend_indicator`, `volatility_ratio`, `bullish_threshold`, `bearish_threshold`, `contradiction_penalty_multiplier`
|
||||
- `RegimeConfig`: all configurable parameters with defaults from design
|
||||
- _Requirements: 7.3_
|
||||
|
||||
- [x] 4.2 Implement `compute_ema` and `classify_regime` functions
|
||||
- `compute_ema`: exponential moving average over last N values
|
||||
- `classify_regime`: compute trend indicator `R = sign(EMA_20 - EMA_100)` and volatility ratio `V_r = σ_20 / σ_100`
|
||||
- Classification rules: trend-following (R≠0 AND V_r<1.2), panic (V_r>1.5), mean-reversion (R=0 AND V_r<1.0), uncertainty (all other)
|
||||
- Adjust thresholds per regime: panic→±0.10, mean-reversion→±0.20, trend-following→±0.15, uncertainty→±0.15 with contradiction multiplier 0.6
|
||||
- Default to uncertainty when data is insufficient (<100 days) or σ values are zero
|
||||
- _Requirements: 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.9_
|
||||
|
||||
- [ ] 5. New module: Source Accuracy Tracker (`services/aggregation/source_accuracy.py`)
|
||||
- [x] 5.1 Implement `SourceAccuracy` dataclass and database functions
|
||||
- `SourceAccuracy` dataclass with `source_id`, `accuracy_ratio`, `sample_count`, `last_updated`
|
||||
- `accuracy_factor` property: return 1.0 when sample_count < 10, else `0.5 + accuracy_ratio`
|
||||
- `fetch_source_accuracy`: batch fetch from `source_accuracy` table via asyncpg
|
||||
- `update_source_accuracy`: update accuracy metrics from realized price outcomes
|
||||
- Handle DB unreachable: return neutral factor 1.0 for all sources
|
||||
- Clamp corrupted accuracy_ratio to [0.0, 1.0]
|
||||
- _Requirements: 4.1, 4.2, 4.3, 4.4, 4.5_
|
||||
|
||||
- [x] 6. Checkpoint — Verify new modules compile and unit tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [ ] 7. Signal Scorer upgrades (`services/aggregation/scoring.py`)
|
||||
- [x] 7.1 Implement sigmoid confidence gate
|
||||
- Add `sigmoid_gate(x, steepness, midpoint)` function: `σ(k·(x - midpoint))`
|
||||
- When `probabilistic=True`, replace binary gate with sigmoid gate in `compute_signal_weight`
|
||||
- When `probabilistic=False`, preserve existing binary gate behavior
|
||||
- _Requirements: 2.1, 2.2, 2.3, 2.4, 2.5_
|
||||
|
||||
- [x] 7.2 Implement information gain surprise weighting
|
||||
- Add `EVENT_TYPE_BASE_RATES` constant dict and `DEFAULT_BASE_RATE = 0.1`
|
||||
- Add `compute_info_gain(event_type, lambda_param, max_gain, default_base_rate)` function: `r = 1 + λ·(-log₂ P(event_type))`, clamped to max 3.0
|
||||
- Integrate as multiplicative factor in combined weight when `probabilistic=True`
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5_
|
||||
|
||||
- [x] 7.3 Implement adaptive recency decay
|
||||
- Add `compute_adaptive_half_life(base_half_life, impact_score, info_gain_factor, market_multiplier, config)` function
|
||||
- Compute `β_impact`, `β_surprise`, `β_market_reaction` scaling factors per design
|
||||
- `τ_i = τ_base · (1 + β_impact) · (1 + β_surprise) · (1 + β_market_reaction)`
|
||||
- When `probabilistic=True`, use adaptive half-life in `recency_weight`; otherwise use fixed
|
||||
- _Requirements: 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7_
|
||||
|
||||
- [x] 7.4 Implement regime multiplier replacing market context multiplier
|
||||
- Add `compute_regime_multiplier(returns, volumes, config)` function
|
||||
- Compute z-scores for return and volume, then `M_regime = 1 + 0.15·|z_r| + 0.10·|z_v|`
|
||||
- Clamp to [1.0, 2.5]; default to 1.0 when data unavailable or σ=0
|
||||
- When `probabilistic=True`, use `M_regime` instead of `M_context` in combined weight
|
||||
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5_
|
||||
|
||||
- [x] 7.5 Integrate source accuracy factor into `compute_signal_weight`
|
||||
- Accept optional `source_accuracy_factor` parameter
|
||||
- When `probabilistic=True`, multiply into combined weight formula
|
||||
- When `probabilistic=False`, ignore (factor = 1.0)
|
||||
- _Requirements: 4.2, 4.3_
|
||||
|
||||
- [x] 7.6 Update `compute_signal_weight` to branch on `probabilistic` flag
|
||||
- When `probabilistic=True`: use sigmoid gate × recency (adaptive) × credibility × (1 + novelty) × info_gain × source_accuracy × regime_multiplier
|
||||
- When `probabilistic=False`: preserve exact current formula (binary gate × recency × credibility × (1 + novelty) × market_context)
|
||||
- Populate all new optional fields on `SignalWeight` and `WeightedSignal`
|
||||
- _Requirements: 16.4, 16.5_
|
||||
|
||||
- [x] 7.7 Write property test for information gain monotonicity
|
||||
- **Property 6: Information Gain Monotonicity**
|
||||
- **Validates: Requirements 3.5**
|
||||
|
||||
- [x] 7.8 Write property test for adaptive decay lower bound
|
||||
- **Property 5: Adaptive Decay Lower Bound**
|
||||
- **Validates: Requirements 5.7, 17.4**
|
||||
|
||||
- [ ] 8. Contradiction upgrade (`services/aggregation/contradiction.py`)
|
||||
- [x] 8.1 Implement weighted disagreement entropy contradiction
|
||||
- Compute `f_pos = W_positive / (W_positive + W_negative)` and `f_neg = 1 - f_pos`
|
||||
- Compute `H_contradiction = -f_pos·log₂(f_pos) - f_neg·log₂(f_neg)`
|
||||
- Weight by evidence mass: `contradiction_score = H_contradiction · min(1.0, (W_pos + W_neg) / W_threshold)`
|
||||
- Return 0.0 when only one direction exists
|
||||
- Preserve existing `ContradictionResult` interface
|
||||
- When `probabilistic=False`, preserve existing minority/majority ratio behavior
|
||||
- _Requirements: 15.1, 15.2, 15.3, 15.4, 15.5, 15.6, 15.7_
|
||||
|
||||
- [x] 8.2 Write property test for contradiction entropy monotonicity
|
||||
- **Property 9: Contradiction Entropy Monotonicity**
|
||||
- **Validates: Requirements 15.7**
|
||||
|
||||
- [ ] 9. Trend Assembly upgrades (`services/aggregation/worker.py`)
|
||||
- [x] 9.1 Integrate Bayesian posterior into trend assembly
|
||||
- When `probabilistic=True`, call `compute_bayesian_posterior` on merged signals
|
||||
- Use Bayesian confidence formula for trend confidence: `0.5 × C_bayesian + 0.25 × F_count + 0.25 × C_avg_credibility - P_contradiction`
|
||||
- Use entropy-based direction: H>0.9→mixed, P_bull>0.65→bullish, P_bull<0.35→bearish, else neutral
|
||||
- Apply regime-adjusted thresholds from `RegimeClassification`
|
||||
- Populate new `TrendSummary` fields: `p_bull`, `alpha`, `beta_param`, `bayesian_confidence`, `entropy`, `regime`, `pipeline_mode`
|
||||
- Store probabilistic outputs in `market_context` JSONB under `"probabilistic"` key
|
||||
- When `probabilistic=False`, preserve exact current heuristic behavior
|
||||
- _Requirements: 1.1, 1.2, 8.1, 8.2, 8.3, 8.4, 8.5, 9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 7.8, 16.4, 16.5_
|
||||
|
||||
- [x] 9.2 Wire regime detection into the aggregation cycle
|
||||
- Call `classify_regime` with closing prices and returns for each ticker
|
||||
- Pass `RegimeClassification` to trend assembly for threshold adjustment
|
||||
- Default to uncertainty regime when market data is unavailable
|
||||
- Persist regime classification in JSONB for auditability
|
||||
- _Requirements: 7.1, 7.2, 7.3, 7.8, 7.9_
|
||||
|
||||
- [ ] 10. Macro scoring upgrade (`services/aggregation/interpolation.py`)
|
||||
- [x] 10.1 Implement multiplicative macro exposure formula
|
||||
- When `probabilistic=True`, compute `S_macro = severity · (1 - Π_k(1 - w_k · O_k))` instead of linear weighted sum
|
||||
- Preserve overlap weights: w_geo=0.35, w_supply=0.25, w_commodity=0.25, w_sector=0.15
|
||||
- Preserve severity mapping and resilience modifier
|
||||
- When `probabilistic=False`, preserve exact current linear formula
|
||||
- _Requirements: 10.1, 10.2, 10.3, 10.4, 10.5, 10.6_
|
||||
|
||||
- [x] 10.2 Implement conditional macro signal integration
|
||||
- When `probabilistic=True` and both company and macro signals exist, apply macro as multiplicative modifier: `S_adjusted = S_company · clamp(1 + M_macro · sign_alignment, 0.5, 1.5)`
|
||||
- When only macro signals exist, fall back to additive behavior with weight 0.3
|
||||
- When only company signals exist, use modifier = 1.0
|
||||
- Log macro modifier value per ticker
|
||||
- When `probabilistic=False`, preserve current additive merge behavior
|
||||
- _Requirements: 11.1, 11.2, 11.3, 11.4, 11.5_
|
||||
|
||||
- [x] 10.3 Write property test for multiplicative macro exposure monotonicity
|
||||
- **Property 7: Multiplicative Macro Exposure Monotonicity**
|
||||
- **Validates: Requirements 10.7, 17.5**
|
||||
|
||||
- [ ] 11. Competitive signal upgrade (`services/aggregation/signal_propagation.py`)
|
||||
- [x] 11.1 Implement graph-distance attenuation for competitive signals
|
||||
- When `probabilistic=True`, compute `S_transfer = S_source · ρ_historical · e^(-d_network)` instead of flat transfer
|
||||
- Compute graph distance as shortest path in competitor relationship graph (cap at 3)
|
||||
- Use 90-day rolling Pearson correlation for `ρ_historical`; default to 0.3 (same-sector) or 0.1 (cross-sector) when insufficient data (<30 days)
|
||||
- Preserve existing relationship strength threshold (R ≥ 0.2) as pre-filter
|
||||
- When `probabilistic=False`, preserve exact current flat transfer behavior
|
||||
- _Requirements: 12.1, 12.2, 12.3, 12.4, 12.5, 12.6, 12.7_
|
||||
|
||||
- [x] 11.2 Write property test for competitive signal distance attenuation
|
||||
- **Property 11: Competitive Signal Distance Attenuation**
|
||||
- **Validates: Requirements 12.7**
|
||||
|
||||
- [ ] 12. Projection upgrade (`services/aggregation/projection.py`)
|
||||
- [x] 12.1 Implement exponentially weighted momentum
|
||||
- When `probabilistic=True`, compute `M_t = Σ_{k=0}^{K-1} λ^k · ΔS_{t-k}` with λ=0.7, K up to 10
|
||||
- Normalize by geometric series sum to produce value in [-1, 1]
|
||||
- Fall back to current heuristic when fewer than 2 historical cycles available
|
||||
- Compute volatility-scaled momentum: `M_adj = M_t / max(σ_20, 0.01)`, clamped to [-2.0, 2.0]
|
||||
- When `probabilistic=False`, preserve exact current simple momentum behavior
|
||||
- _Requirements: 13.1, 13.2, 13.3, 13.4, 13.5, 13.6_
|
||||
|
||||
- [x] 12.2 Write property test for exponentially weighted momentum direction
|
||||
- **Property 10: Exponentially Weighted Momentum Direction**
|
||||
- **Validates: Requirements 13.6, 17.6**
|
||||
|
||||
- [ ] 13. Recommendation upgrade (`services/recommendation/eligibility.py`)
|
||||
- [x] 13.1 Implement expected value recommendation gate
|
||||
- When `probabilistic=True`, compute `EV = P_bull · R_up - P_bear · R_down`
|
||||
- Estimate `R_up = strength · σ_20 · √(horizon_days)` and `R_down = (1 - strength) · σ_20 · √(horizon_days)`
|
||||
- When EV > threshold (default 0.005), allow recommendation through existing gates
|
||||
- When EV ≤ threshold, force recommendation to informational mode
|
||||
- Persist EV in `risk_checks` JSONB of `recommendation_evaluations`
|
||||
- Populate `expected_value`, `p_bull`, `pipeline_mode` on Recommendation model
|
||||
- Preserve all existing eligibility gates as additional requirements
|
||||
- When `probabilistic=False`, skip EV gate entirely
|
||||
- _Requirements: 14.1, 14.2, 14.3, 14.4, 14.5, 14.6_
|
||||
|
||||
- [x] 13.2 Write property test for expected value directional consistency
|
||||
- **Property 12: Expected Value Directional Consistency**
|
||||
- **Validates: Requirements 17.8**
|
||||
|
||||
- [x] 14. Checkpoint — Verify all pipeline stages compile and existing tests still pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
- [ ] 15. Integration wiring and feature flag plumbing
|
||||
- [x] 15.1 Wire feature flag through the aggregation worker entry point
|
||||
- Read `probabilistic_scoring_enabled` from `risk_configs` at cycle start in `services/aggregation/worker.py`
|
||||
- Pass flag to `ScoringConfig`, trend assembly, contradiction, macro, competitive, and projection stages
|
||||
- Log pipeline mode at cycle start
|
||||
- Ensure flag is read once per cycle (mid-cycle changes take effect next cycle)
|
||||
- _Requirements: 16.3, 16.6, 16.7_
|
||||
|
||||
- [x] 15.2 Wire source accuracy fetch into the scoring pipeline
|
||||
- At cycle start, batch-fetch source accuracy for all source IDs in the current signal set
|
||||
- Pass `source_accuracy_factor` to `compute_signal_weight` for each signal
|
||||
- Handle DB errors gracefully (default to 1.0)
|
||||
- _Requirements: 4.1, 4.2, 4.3_
|
||||
|
||||
- [x] 15.3 Wire regime detection into the aggregation cycle
|
||||
- Fetch closing prices and returns for each ticker from market data
|
||||
- Call `classify_regime` and pass result to trend assembly and scoring stages
|
||||
- Handle missing market data (default to uncertainty regime)
|
||||
- _Requirements: 7.1, 7.8, 7.9_
|
||||
|
||||
- [x] 15.4 Store probabilistic outputs in existing JSONB columns
|
||||
- Store Bayesian fields in `trend_windows.market_context` JSONB under `"probabilistic"` key
|
||||
- Store EV fields in `recommendation_evaluations.risk_checks` JSONB
|
||||
- Store regime classification in trend window JSONB
|
||||
- _Requirements: 16.2_
|
||||
|
||||
- [ ] 16. Numerical stability and edge case hardening
|
||||
- [x] 16.1 Add input validation and edge case guards across all new functions
|
||||
- Guard `log₂(0)` in entropy and information gain computations
|
||||
- Floor `max(σ_20, 0.01)` for momentum volatility scaling
|
||||
- Default to uncertainty regime when σ values are zero
|
||||
- Return `M_regime = 1.0` when z-score σ = 0
|
||||
- Skip signals with NaN weight or sentiment
|
||||
- Clamp all outputs to documented ranges
|
||||
- _Requirements: 17.9, 6.4_
|
||||
|
||||
- [x] 16.2 Write property test for numerical stability across all formulas
|
||||
- **Property 14: Numerical Stability Across All Formulas**
|
||||
- **Validates: Requirements 17.9, 6.4**
|
||||
|
||||
- [ ] 17. Unit tests for all new and modified modules
|
||||
- [x] 17.1 Write unit tests for Bayesian accumulator (`tests/test_bayesian.py`)
|
||||
- Test uninformative prior (empty signals → P_bull=0.5, α=1, β=1, C=0)
|
||||
- Test specific sigmoid gate values (x=0.5→0.5, x=0.2→<0.05, x=0.8→>0.95)
|
||||
- Test entropy direction mapping (H>0.9→mixed, P_bull>0.65→bullish, etc.)
|
||||
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5_
|
||||
|
||||
- [x] 17.2 Write unit tests for regime detector (`tests/test_regime.py`)
|
||||
- Test specific (R, V_r) → expected regime classification
|
||||
- Test threshold adjustments per regime (panic→0.10, mean_reversion→0.20)
|
||||
- Test insufficient data fallback to uncertainty
|
||||
- _Requirements: 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.9_
|
||||
|
||||
- [x] 17.3 Write unit tests for source accuracy tracker (`tests/test_source_accuracy.py`)
|
||||
- Test accuracy_factor property: sample_count < 10 → 1.0, else 0.5 + ratio
|
||||
- Test corrupted data clamping
|
||||
- _Requirements: 4.1, 4.2, 4.3_
|
||||
|
||||
- [x] 17.4 Write unit tests for signal scoring upgrades (`tests/test_signal_math_unit.py`)
|
||||
- Test info gain clamp (very rare event → factor ≤ 3.0)
|
||||
- Test default base rate (unknown event type → 0.1)
|
||||
- Test adaptive decay edge cases (all zeros → τ_base, all max → 6×τ_base)
|
||||
- Test zero overlap → zero macro impact
|
||||
- Test max overlap → ≈severity×0.724
|
||||
- Test macro fallback behaviors (only macro → additive, only company → no modifier)
|
||||
- Test graph distance cutoff (d>3 → no propagation)
|
||||
- Test momentum fallback (<2 cycles → heuristic)
|
||||
- Test EV threshold behavior (EV>0.005→proceed, EV≤0.005→informational)
|
||||
- Test feature flag behaviors (flag=false→heuristic, flag=true→probabilistic)
|
||||
- _Requirements: 3.1, 3.4, 5.5, 5.6, 10.3, 10.4, 11.3, 13.3, 14.3, 14.4, 16.4, 16.5_
|
||||
|
||||
- [x] 18. Final checkpoint — Ensure all tests pass
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
|
||||
## Notes
|
||||
|
||||
- Tasks marked with `*` are optional and can be skipped for faster MVP
|
||||
- Each task references specific requirements for traceability
|
||||
- Checkpoints ensure incremental validation after each major phase
|
||||
- Property tests validate the 14 universal correctness properties from the design document
|
||||
- Unit tests validate specific examples, edge cases, and integration points
|
||||
- The design uses Python throughout — no language selection needed
|
||||
- Migration number is 034 (existing migrations go up to 033)
|
||||
- All new dataclass fields use optional defaults for backward compatibility
|
||||
- Feature flag `probabilistic_scoring_enabled` gates every behavioral change
|
||||
Binary file not shown.
@@ -0,0 +1 @@
|
||||
{"specId": "d76705a8-fb91-4fce-b59e-c4b3b0dbbd83", "workflowType": "requirements-first", "specType": "feature"}
|
||||
@@ -0,0 +1,802 @@
|
||||
# Design Document — Trading Feedback Engine
|
||||
|
||||
## Overview
|
||||
|
||||
This design adds a periodic trading performance reporting system to Stonks Oracle. The system collects trading data (P&L, recommendations, positions, risk metrics, model quality), generates structured JSON reports with AI-powered summaries, validates report metrics against live data, and stores reports for retrieval via API.
|
||||
|
||||
The core challenge is fitting AI summarization within the 8k-token context window of the `qwen3.5:9b-fast` model on the local Ollama instance. The design addresses this with a chunking strategy that serializes report section data into ≤6,000-character chunks, summarizes each chunk independently, then merges chunk summaries into a final section summary. This hierarchical summarization approach keeps each LLM call well within the token budget while producing coherent narratives.
|
||||
|
||||
### Design Rationale
|
||||
|
||||
A trading system without periodic performance feedback forces the operator to manually query tables and compute metrics. The feedback engine closes this gap by:
|
||||
|
||||
1. **Automating data collection** — pulling from 7+ tables (trading_decisions, orders, positions, portfolio_snapshots, recommendations, prediction_outcomes, model_metric_snapshots) into a single structured report
|
||||
2. **AI-powered summarization** — using the existing agent infrastructure (ai_agents, AgentConfigResolver, llm_factory) to generate natural-language summaries that highlight trends and anomalies
|
||||
3. **Cross-validation** — comparing computed metrics against live validation data (prediction_outcomes, model_metric_snapshots) and flagging discrepancies >5%
|
||||
4. **Persistent storage** — storing reports as JSONB for historical comparison and trend analysis
|
||||
5. **Scheduled generation** — daily (after market close) and weekly (Saturday) reports via Redis queue jobs
|
||||
|
||||
The design reuses existing infrastructure: asyncpg for persistence, FastAPI for API endpoints, Redis queues for async job processing, the ai_agents/AgentConfigResolver/llm_factory stack for LLM access, and TanStack Query hooks on the frontend.
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
### High-Level Data Flow
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph "Scheduling (Trigger)"
|
||||
A[Scheduler Service] -->|after 16:30 ET daily| B[Redis Queue<br/>stonks:queue:report_generation]
|
||||
A -->|Saturday weekly| B
|
||||
C[Manual API Trigger] --> B
|
||||
end
|
||||
|
||||
subgraph "Report Generation (Async Worker)"
|
||||
B --> D[Report Generator<br/>services/reporting/generator.py]
|
||||
D -->|1. Collect| E[Data Collector<br/>services/reporting/collector.py]
|
||||
E -->|queries| F[(trading_decisions<br/>orders, positions<br/>portfolio_snapshots<br/>recommendations)]
|
||||
D -->|2. Build sections| G[Section Builder<br/>services/reporting/sections.py]
|
||||
G -->|P&L, accuracy,<br/>positions, risk,<br/>model quality| H[Report Sections]
|
||||
D -->|3. Validate| I[Report Validator<br/>services/reporting/validator.py]
|
||||
I -->|cross-check| J[(prediction_outcomes<br/>model_metric_snapshots)]
|
||||
D -->|4. Summarize| K[AI Summarizer<br/>services/reporting/summarizer.py]
|
||||
K -->|chunk & summarize| L[Report_Summarizer_Agent<br/>via AgentConfigResolver<br/>+ llm_factory]
|
||||
D -->|5. Store| M[(trading_reports table)]
|
||||
end
|
||||
|
||||
subgraph "API Layer"
|
||||
N[GET /api/reports] -->|paginated list| M
|
||||
O[GET /api/reports/:id] -->|full report| M
|
||||
end
|
||||
|
||||
subgraph "Frontend"
|
||||
P[useReports hook] --> N
|
||||
Q[useReport hook] --> O
|
||||
end
|
||||
```
|
||||
|
||||
### Scheduling Strategy
|
||||
|
||||
| Component | Trigger | Cadence |
|
||||
|-----------|---------|---------|
|
||||
| Daily Report | Scheduler after 16:30 ET | Every trading day |
|
||||
| Weekly Report | Scheduler on Saturday | Weekly (Mon–Fri coverage) |
|
||||
| Report Generator Worker | Redis queue consumer | On-demand from queue |
|
||||
| AI Summarizer | Called by generator | Per report section |
|
||||
|
||||
### Chunking Strategy
|
||||
|
||||
The `qwen3.5:9b-fast` model has an 8k-token context window. With the system prompt (~200 tokens) and response budget (~200 tokens), roughly 7,600 tokens remain for input. At ~4 chars/token for structured data, that's ~30,400 characters. The 6,000-character chunk limit provides a 5x safety margin to account for JSON overhead, prompt framing, and tokenization variance.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Section Data<br/>e.g. 15,000 chars] --> B{> 6,000 chars?}
|
||||
B -->|No| C[Single LLM call<br/>→ summary]
|
||||
B -->|Yes| D[Split into chunks<br/>≤ 6,000 chars each]
|
||||
D --> E[Chunk 1 → LLM → summary 1]
|
||||
D --> F[Chunk 2 → LLM → summary 2]
|
||||
D --> G[Chunk N → LLM → summary N]
|
||||
E --> H[Merge summaries<br/>→ final LLM call<br/>→ section summary]
|
||||
F --> H
|
||||
G --> H
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Components and Interfaces
|
||||
|
||||
### New Modules
|
||||
|
||||
| Module | File | Responsibility |
|
||||
|--------|------|----------------|
|
||||
| Report Data Collector | `services/reporting/collector.py` | Queries trading data for a reporting period |
|
||||
| Report Section Builder | `services/reporting/sections.py` | Builds structured report sections from raw data |
|
||||
| Report Validator | `services/reporting/validator.py` | Cross-checks metrics against validation tables |
|
||||
| AI Summarizer | `services/reporting/summarizer.py` | Chunks data and generates AI summaries |
|
||||
| Report Generator | `services/reporting/generator.py` | Orchestrates the full report generation pipeline |
|
||||
| Report Models | `services/reporting/models.py` | Pydantic models for report structure and serialization |
|
||||
|
||||
### Modified Modules
|
||||
|
||||
| Module | File | Changes |
|
||||
|--------|------|---------|
|
||||
| Query API | `services/api/app.py` | 2 new `/api/reports` endpoints |
|
||||
| Redis Keys | `services/shared/redis_keys.py` | New `QUEUE_REPORT_GENERATION` constant |
|
||||
| Frontend Hooks | `frontend/src/api/hooks.ts` | 2 new report hooks |
|
||||
| DB Migration | `infra/migrations/038_trading_reports.sql` | New table + agent seed |
|
||||
|
||||
### Component Interface Details
|
||||
|
||||
#### 1. Report Models (`services/reporting/models.py`)
|
||||
|
||||
```python
|
||||
from __future__ import annotations
|
||||
from datetime import date, datetime
|
||||
from enum import Enum
|
||||
from typing import Optional
|
||||
from pydantic import BaseModel, Field
|
||||
|
||||
|
||||
class ReportType(str, Enum):
|
||||
DAILY = "daily"
|
||||
WEEKLY = "weekly"
|
||||
|
||||
|
||||
class ValidationStatus(str, Enum):
|
||||
PASSED = "passed"
|
||||
WARNINGS = "warnings"
|
||||
|
||||
|
||||
class ValidationWarning(BaseModel):
|
||||
field_name: str
|
||||
computed_value: float
|
||||
snapshot_value: float
|
||||
pct_difference: float
|
||||
|
||||
|
||||
class PLSection(BaseModel):
|
||||
realized_pnl: float
|
||||
unrealized_pnl: float
|
||||
daily_return: float
|
||||
cumulative_return: float
|
||||
win_count: int
|
||||
loss_count: int
|
||||
win_rate: float
|
||||
profit_factor: float
|
||||
sharpe_ratio: float
|
||||
summary: str = ""
|
||||
validation_warnings: list[ValidationWarning] = Field(default_factory=list)
|
||||
|
||||
|
||||
class RecommendationAccuracySection(BaseModel):
|
||||
total_evaluated: int
|
||||
act_count: int
|
||||
skip_count: int
|
||||
acted_win_rate: float
|
||||
avg_confidence_acted: float
|
||||
avg_confidence_skipped: float
|
||||
summary: str = ""
|
||||
validation_warnings: list[ValidationWarning] = Field(default_factory=list)
|
||||
|
||||
|
||||
class PositionDetail(BaseModel):
|
||||
ticker: str
|
||||
entry_price: float
|
||||
current_or_exit_price: float
|
||||
pnl: float
|
||||
pnl_pct: float
|
||||
hold_duration_hours: float
|
||||
status: str # "open" or "closed"
|
||||
|
||||
|
||||
class PositionPerformanceSection(BaseModel):
|
||||
positions: list[PositionDetail] = Field(default_factory=list)
|
||||
summary: str = ""
|
||||
|
||||
|
||||
class RiskMetricsSection(BaseModel):
|
||||
current_risk_tier: str
|
||||
portfolio_heat: float
|
||||
max_drawdown: float
|
||||
current_drawdown_pct: float
|
||||
reserve_pool_balance: float
|
||||
circuit_breaker_event_count: int
|
||||
summary: str = ""
|
||||
|
||||
|
||||
class ModelQualityWindow(BaseModel):
|
||||
lookback: str
|
||||
win_rate: float | None
|
||||
directional_accuracy: float | None
|
||||
information_coefficient: float | None
|
||||
calibration_error: float | None
|
||||
brier_score: float | None
|
||||
|
||||
|
||||
class ModelQualitySection(BaseModel):
|
||||
windows: list[ModelQualityWindow] = Field(default_factory=list)
|
||||
summary: str = ""
|
||||
validation_warnings: list[ValidationWarning] = Field(default_factory=list)
|
||||
|
||||
|
||||
class ReportData(BaseModel):
|
||||
"""Top-level report structure stored as JSONB."""
|
||||
pnl: PLSection
|
||||
recommendation_accuracy: RecommendationAccuracySection
|
||||
position_performance: PositionPerformanceSection
|
||||
risk_metrics: RiskMetricsSection
|
||||
model_quality: ModelQualitySection
|
||||
executive_summary: str = ""
|
||||
validation_status: ValidationStatus = ValidationStatus.PASSED
|
||||
generated_at: datetime
|
||||
period_start: date
|
||||
period_end: date
|
||||
report_type: ReportType
|
||||
```
|
||||
|
||||
#### 2. Report Data Collector (`services/reporting/collector.py`)
|
||||
|
||||
```python
|
||||
from __future__ import annotations
|
||||
from dataclasses import dataclass
|
||||
from datetime import date, datetime
|
||||
import asyncpg
|
||||
|
||||
|
||||
@dataclass
|
||||
class CollectedData:
|
||||
"""Raw data collected for a reporting period."""
|
||||
trading_decisions: list[dict]
|
||||
orders: list[dict]
|
||||
open_positions: list[dict]
|
||||
closed_positions: list[dict]
|
||||
portfolio_snapshot: dict | None
|
||||
previous_portfolio_snapshot: dict | None
|
||||
recommendations: list[dict]
|
||||
prediction_outcomes: list[dict]
|
||||
model_metric_snapshots: list[dict]
|
||||
circuit_breaker_events: list[dict]
|
||||
reserve_pool_balance: float
|
||||
|
||||
|
||||
async def collect_report_data(
|
||||
pool: asyncpg.Pool,
|
||||
period_start: date,
|
||||
period_end: date,
|
||||
) -> CollectedData:
|
||||
"""Query all trading data for the reporting period.
|
||||
|
||||
Queries: trading_decisions, orders, positions, portfolio_snapshots,
|
||||
recommendations, prediction_outcomes, model_metric_snapshots,
|
||||
circuit_breaker_events, reserve_pool_ledger.
|
||||
|
||||
Returns CollectedData with all raw query results.
|
||||
If no trading_decisions exist, returns empty lists (zero-activity).
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### 3. Report Section Builder (`services/reporting/sections.py`)
|
||||
|
||||
```python
|
||||
from __future__ import annotations
|
||||
from services.reporting.models import (
|
||||
PLSection, RecommendationAccuracySection,
|
||||
PositionPerformanceSection, PositionDetail,
|
||||
RiskMetricsSection, ModelQualitySection, ModelQualityWindow,
|
||||
)
|
||||
from services.reporting.collector import CollectedData
|
||||
|
||||
|
||||
def build_pnl_section(data: CollectedData) -> PLSection:
|
||||
"""Build P&L section from collected data.
|
||||
|
||||
Computes realized/unrealized P&L, daily return, cumulative return,
|
||||
win/loss counts, win rate, profit factor, and Sharpe ratio from
|
||||
portfolio_snapshot and closed positions.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def build_recommendation_accuracy_section(data: CollectedData) -> RecommendationAccuracySection:
|
||||
"""Build recommendation accuracy section.
|
||||
|
||||
Joins trading_decisions with prediction_outcomes to compute
|
||||
act/skip breakdown, win rate of acted recommendations, and
|
||||
average confidence of acted vs skipped.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def build_position_performance_section(data: CollectedData) -> PositionPerformanceSection:
|
||||
"""Build position performance section.
|
||||
|
||||
Lists each position (open and closed) with entry price,
|
||||
current/exit price, P&L, P&L%, and hold duration.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def build_risk_metrics_section(data: CollectedData) -> RiskMetricsSection:
|
||||
"""Build risk metrics section.
|
||||
|
||||
Extracts current risk tier, portfolio heat, max drawdown,
|
||||
current drawdown %, reserve pool balance, and circuit breaker
|
||||
event count from collected data.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def build_model_quality_section(data: CollectedData) -> ModelQualitySection:
|
||||
"""Build model quality section.
|
||||
|
||||
Extracts latest model_metric_snapshot values for 7d, 30d, 90d
|
||||
lookback windows.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### 4. Report Validator (`services/reporting/validator.py`)
|
||||
|
||||
```python
|
||||
from __future__ import annotations
|
||||
import asyncpg
|
||||
from services.reporting.models import (
|
||||
ReportData, ValidationStatus, ValidationWarning,
|
||||
)
|
||||
|
||||
|
||||
DISCREPANCY_THRESHOLD_PCT = 5.0
|
||||
|
||||
|
||||
def validate_recommendation_accuracy(
|
||||
section: "RecommendationAccuracySection",
|
||||
prediction_outcomes: list[dict],
|
||||
) -> list[ValidationWarning]:
|
||||
"""Cross-reference reported win rates with prediction_outcomes.
|
||||
|
||||
Compares computed win rate against direction_correct/profitable
|
||||
fields from prediction_outcomes for the same tickers and period.
|
||||
Returns warnings for discrepancies > 5%.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def validate_model_quality(
|
||||
section: "ModelQualitySection",
|
||||
metric_snapshots: list[dict],
|
||||
) -> list[ValidationWarning]:
|
||||
"""Compare reported model quality metrics against model_metric_snapshots.
|
||||
|
||||
Flags discrepancies > 5% between computed and snapshot values
|
||||
for win_rate, directional_accuracy, IC, ECE, and Brier score.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def compute_validation_status(report: ReportData) -> ValidationStatus:
|
||||
"""Determine overall validation status.
|
||||
|
||||
Returns 'passed' if no warnings across all sections,
|
||||
'warnings' if any section has validation warnings.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### 5. AI Summarizer (`services/reporting/summarizer.py`)
|
||||
|
||||
```python
|
||||
from __future__ import annotations
|
||||
import asyncpg
|
||||
from services.shared.agent_config import AgentConfigResolver
|
||||
|
||||
|
||||
CHUNK_SIZE_LIMIT = 6000 # characters per chunk
|
||||
MAX_SUMMARY_WORDS = 200 # per section summary
|
||||
MAX_EXECUTIVE_SUMMARY_WORDS = 300
|
||||
|
||||
|
||||
def chunk_data(serialized: str, max_chars: int = CHUNK_SIZE_LIMIT) -> list[str]:
|
||||
"""Split serialized data into chunks of at most max_chars.
|
||||
|
||||
Splits on newline boundaries to avoid breaking JSON structures.
|
||||
Each chunk is ≤ max_chars characters.
|
||||
Returns at least one chunk (even if empty input).
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
async def summarize_section(
|
||||
pool: asyncpg.Pool,
|
||||
resolver: AgentConfigResolver,
|
||||
section_name: str,
|
||||
section_data: str,
|
||||
) -> str:
|
||||
"""Generate AI summary for a report section.
|
||||
|
||||
1. Serialize section data to string
|
||||
2. Chunk if > CHUNK_SIZE_LIMIT
|
||||
3. Summarize each chunk via Report_Summarizer_Agent
|
||||
4. If multiple chunks, merge summaries with a final LLM call
|
||||
5. Log each invocation to agent_performance_log
|
||||
6. On failure after max_retries, fall back to deterministic summary
|
||||
|
||||
Uses AgentConfigResolver to resolve agent config by slug
|
||||
'report-summarizer', then llm_factory to build the LLM client.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
def build_deterministic_summary(section_name: str, section_data: dict) -> str:
|
||||
"""Build a fallback deterministic summary from raw metrics.
|
||||
|
||||
Produces a template-based text summary when AI summarization fails.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
async def generate_executive_summary(
|
||||
pool: asyncpg.Pool,
|
||||
resolver: AgentConfigResolver,
|
||||
section_summaries: dict[str, str],
|
||||
) -> str:
|
||||
"""Generate executive summary from all section summaries.
|
||||
|
||||
Concatenates section summaries, chunks if needed, and produces
|
||||
a ≤300-word synthesis via the Report_Summarizer_Agent.
|
||||
Falls back to concatenated section summaries on failure.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### 6. Report Generator (`services/reporting/generator.py`)
|
||||
|
||||
```python
|
||||
from __future__ import annotations
|
||||
from datetime import date
|
||||
import asyncpg
|
||||
from services.reporting.models import ReportData, ReportType
|
||||
|
||||
|
||||
async def generate_report(
|
||||
pool: asyncpg.Pool,
|
||||
report_type: ReportType,
|
||||
period_start: date,
|
||||
period_end: date,
|
||||
) -> ReportData:
|
||||
"""Orchestrate full report generation.
|
||||
|
||||
1. Collect data via collector
|
||||
2. Build sections via section builder
|
||||
3. Validate sections via validator
|
||||
4. Generate AI summaries via summarizer
|
||||
5. Generate executive summary
|
||||
6. Assemble final ReportData
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
async def store_report(
|
||||
pool: asyncpg.Pool,
|
||||
report: ReportData,
|
||||
) -> str:
|
||||
"""Store report in trading_reports table.
|
||||
|
||||
Uses INSERT ... ON CONFLICT (report_type, period_start, period_end)
|
||||
DO UPDATE to handle regeneration of existing reports.
|
||||
|
||||
Returns the report UUID.
|
||||
"""
|
||||
...
|
||||
|
||||
|
||||
async def process_report_job(
|
||||
pool: asyncpg.Pool,
|
||||
job: dict,
|
||||
) -> None:
|
||||
"""Process a report generation job from the Redis queue.
|
||||
|
||||
Deserializes job payload, calls generate_report + store_report.
|
||||
Handles retries with exponential backoff (up to 3 attempts).
|
||||
Rejects duplicate jobs for the same report_type + period.
|
||||
"""
|
||||
...
|
||||
```
|
||||
|
||||
#### 7. API Endpoints (added to `services/api/app.py`)
|
||||
|
||||
| Endpoint | Method | Parameters | Returns |
|
||||
|----------|--------|------------|---------|
|
||||
| `GET /api/reports` | GET | `report_type`, `start_date`, `end_date`, `limit`, `offset` | Paginated list: id, report_type, period_start, period_end, validation_status, generated_at |
|
||||
| `GET /api/reports/{report_id}` | GET | — | Full report including report_data JSONB |
|
||||
|
||||
#### 8. Frontend Hooks (added to `frontend/src/api/hooks.ts`)
|
||||
|
||||
```typescript
|
||||
export interface ReportListItem {
|
||||
id: string;
|
||||
report_type: string;
|
||||
period_start: string;
|
||||
period_end: string;
|
||||
validation_status: string;
|
||||
generated_at: string;
|
||||
}
|
||||
|
||||
export interface ReportDetail extends ReportListItem {
|
||||
report_data: Record<string, unknown>;
|
||||
created_at: string;
|
||||
}
|
||||
|
||||
export function useReports(params?: {
|
||||
report_type?: string;
|
||||
start_date?: string;
|
||||
end_date?: string;
|
||||
limit?: number;
|
||||
offset?: number;
|
||||
}) {
|
||||
const qs = new URLSearchParams();
|
||||
if (params?.report_type) qs.set('report_type', params.report_type);
|
||||
if (params?.start_date) qs.set('start_date', params.start_date);
|
||||
if (params?.end_date) qs.set('end_date', params.end_date);
|
||||
if (params?.limit) qs.set('limit', String(params.limit));
|
||||
if (params?.offset) qs.set('offset', String(params.offset));
|
||||
const path = `/api/reports${qs.toString() ? '?' + qs : ''}`;
|
||||
return useGet<ReportListItem[]>(['reports', params], 'query', path);
|
||||
}
|
||||
|
||||
export function useReport(id: string | undefined) {
|
||||
return useGet<ReportDetail>(
|
||||
['report', id], 'query', `/api/reports/${id}`, !!id
|
||||
);
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Data Models
|
||||
|
||||
### Database Schema (Migration 038)
|
||||
|
||||
#### trading_reports
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS trading_reports (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
report_type VARCHAR(20) NOT NULL,
|
||||
period_start DATE NOT NULL,
|
||||
period_end DATE NOT NULL,
|
||||
report_data JSONB NOT NULL,
|
||||
validation_status VARCHAR(20) NOT NULL DEFAULT 'passed',
|
||||
generated_at TIMESTAMPTZ NOT NULL,
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
|
||||
CONSTRAINT uq_trading_reports_period UNIQUE (report_type, period_start, period_end),
|
||||
CONSTRAINT chk_report_type CHECK (report_type IN ('daily', 'weekly'))
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_trading_reports_type ON trading_reports(report_type);
|
||||
CREATE INDEX IF NOT EXISTS idx_trading_reports_period ON trading_reports(period_start, period_end);
|
||||
CREATE INDEX IF NOT EXISTS idx_trading_reports_generated ON trading_reports(generated_at DESC);
|
||||
```
|
||||
|
||||
#### Report Summarizer Agent Seed
|
||||
|
||||
```sql
|
||||
INSERT INTO ai_agents (name, slug, purpose, model_provider, model_name, system_prompt, prompt_version, schema_version, temperature, max_tokens, timeout_seconds, max_retries, source)
|
||||
SELECT * FROM (VALUES
|
||||
(
|
||||
'Report Summarizer',
|
||||
'report-summarizer',
|
||||
'Generates concise natural-language summaries of trading performance report sections. Processes chunked data within the 8k-token context window.',
|
||||
'ollama',
|
||||
'qwen3.5:9b-fast',
|
||||
E'You are a concise financial performance analyst. You summarize trading performance data into clear, professional prose.\n\nSTRICT RULES:\n1. Do NOT fabricate any data not present in the input.\n2. Do NOT add opinions, predictions, or recommendations.\n3. Keep each summary under 200 words.\n4. Highlight notable trends, outliers, and changes from prior periods.\n5. Use precise numbers from the input data.\n6. Use a neutral, professional tone.\n7. Return ONLY the summary text. No JSON, no markdown, no commentary.',
|
||||
'report-summarizer-v1',
|
||||
'1.0.0',
|
||||
0.0,
|
||||
1024,
|
||||
60,
|
||||
2,
|
||||
'system'
|
||||
)
|
||||
) AS v(name, slug, purpose, model_provider, model_name, system_prompt, prompt_version, schema_version, temperature, max_tokens, timeout_seconds, max_retries, source)
|
||||
WHERE NOT EXISTS (SELECT 1 FROM ai_agents WHERE slug = 'report-summarizer');
|
||||
```
|
||||
|
||||
### Report JSONB Structure
|
||||
|
||||
The `report_data` column stores a JSON object matching the `ReportData` Pydantic model:
|
||||
|
||||
```json
|
||||
{
|
||||
"pnl": {
|
||||
"realized_pnl": 125.50,
|
||||
"unrealized_pnl": -30.20,
|
||||
"daily_return": 0.012,
|
||||
"cumulative_return": 0.085,
|
||||
"win_count": 8,
|
||||
"loss_count": 3,
|
||||
"win_rate": 0.727,
|
||||
"profit_factor": 2.15,
|
||||
"sharpe_ratio": 1.42,
|
||||
"summary": "AI-generated summary...",
|
||||
"validation_warnings": []
|
||||
},
|
||||
"recommendation_accuracy": {
|
||||
"total_evaluated": 15,
|
||||
"act_count": 8,
|
||||
"skip_count": 7,
|
||||
"acted_win_rate": 0.75,
|
||||
"avg_confidence_acted": 0.72,
|
||||
"avg_confidence_skipped": 0.48,
|
||||
"summary": "AI-generated summary...",
|
||||
"validation_warnings": []
|
||||
},
|
||||
"position_performance": {
|
||||
"positions": [
|
||||
{
|
||||
"ticker": "AAPL",
|
||||
"entry_price": 185.50,
|
||||
"current_or_exit_price": 192.30,
|
||||
"pnl": 68.00,
|
||||
"pnl_pct": 3.66,
|
||||
"hold_duration_hours": 72.5,
|
||||
"status": "open"
|
||||
}
|
||||
],
|
||||
"summary": "AI-generated summary..."
|
||||
},
|
||||
"risk_metrics": {
|
||||
"current_risk_tier": "moderate",
|
||||
"portfolio_heat": 0.12,
|
||||
"max_drawdown": 0.08,
|
||||
"current_drawdown_pct": 0.03,
|
||||
"reserve_pool_balance": 450.00,
|
||||
"circuit_breaker_event_count": 1,
|
||||
"summary": "AI-generated summary..."
|
||||
},
|
||||
"model_quality": {
|
||||
"windows": [
|
||||
{
|
||||
"lookback": "7d",
|
||||
"win_rate": 0.65,
|
||||
"directional_accuracy": 0.62,
|
||||
"information_coefficient": 0.08,
|
||||
"calibration_error": 0.12,
|
||||
"brier_score": 0.22
|
||||
}
|
||||
],
|
||||
"summary": "AI-generated summary...",
|
||||
"validation_warnings": []
|
||||
},
|
||||
"executive_summary": "AI-generated executive summary...",
|
||||
"validation_status": "passed",
|
||||
"generated_at": "2025-01-15T21:30:00Z",
|
||||
"period_start": "2025-01-15",
|
||||
"period_end": "2025-01-15",
|
||||
"report_type": "daily"
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Correctness Properties
|
||||
|
||||
*A property is a characteristic or behavior that should hold true across all valid executions of a system — essentially, a formal statement about what the system should do. Properties serve as the bridge between human-readable specifications and machine-verifiable correctness guarantees.*
|
||||
|
||||
The following properties were derived from the acceptance criteria through systematic prework analysis. After reflection, 5 unique properties remain. Report section structure checks (3.1–3.5) are subsumed by the round-trip property — if a ReportData object survives serialization and deserialization, its structure is correct by construction (Pydantic enforces required fields). Validation status computation (4.4) is subsumed by the discrepancy detection property. ISO 8601 datetime formatting (8.4) is verified as part of the round-trip property since Pydantic's JSON serialization uses ISO 8601 by default and the round-trip would fail if datetimes were mangled.
|
||||
|
||||
### Property 1: Chunking Round-Trip and Size Constraint
|
||||
|
||||
*For any* input string, splitting it into chunks with a maximum size limit SHALL produce chunks where (a) every chunk is ≤ the size limit in characters, (b) no chunk is empty (except when the input itself is empty, which produces exactly one empty chunk), and (c) concatenating all chunks in order reconstructs the original input string.
|
||||
|
||||
**Validates: Requirements 2.2**
|
||||
|
||||
### Property 2: Report Serialization Round-Trip
|
||||
|
||||
*For any* valid ReportData object (with valid P&L, recommendation accuracy, position performance, risk metrics, and model quality sections), serializing to JSON and then deserializing back SHALL produce a ReportData object equivalent to the original. All datetime fields in the serialized JSON SHALL be in ISO 8601 format.
|
||||
|
||||
**Validates: Requirements 8.1, 8.2, 8.3, 8.4**
|
||||
|
||||
### Property 3: Validation Discrepancy Detection Correctness
|
||||
|
||||
*For any* pair of computed metric value and snapshot metric value (both finite, non-negative floats), the validation function SHALL produce a warning if and only if the percentage difference exceeds 5%. The percentage difference SHALL be computed as `|computed - snapshot| / snapshot * 100` when snapshot > 0, and SHALL flag any non-zero computed value when snapshot is 0.
|
||||
|
||||
**Validates: Requirements 4.1, 4.2, 4.3, 4.4**
|
||||
|
||||
### Property 4: Recommendation Accuracy Aggregation
|
||||
|
||||
*For any* non-empty list of trading decisions with associated prediction outcomes (each having a boolean `direction_correct`, boolean `profitable`, and float `excess_return_vs_spy`), the computed win rate SHALL equal the count of profitable outcomes divided by total outcomes, the directional accuracy SHALL equal the count of direction-correct outcomes divided by total outcomes, and the average excess return SHALL equal the arithmetic mean of all excess_return_vs_spy values. All three values SHALL be in [0.0, 1.0] for rates and finite for the average.
|
||||
|
||||
**Validates: Requirements 1.4**
|
||||
|
||||
### Property 5: Portfolio Period-Over-Period Delta Computation
|
||||
|
||||
*For any* two valid portfolio snapshots (current and previous) with non-negative portfolio_value, active_pool, reserve_pool, and finite cumulative_return, the period-over-period deltas SHALL equal (current - previous) for each field. When no previous snapshot exists, the deltas SHALL be zero.
|
||||
|
||||
**Validates: Requirements 1.3**
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Data Collection Failures
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| No trading_decisions for period | Generate zero-activity report with note "No trading activity during this period" |
|
||||
| No portfolio_snapshot for period | Use most recent snapshot before period_start; if none exists, use zero values |
|
||||
| No prediction_outcomes for period | Skip recommendation accuracy validation; set validation_warnings noting missing data |
|
||||
| No model_metric_snapshots for period | Model quality section shows NULL values for all metrics |
|
||||
| Database connection failure during collection | Propagate error to job processor for retry |
|
||||
|
||||
### AI Summarization Failures
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| LLM timeout (>60s) | Retry up to max_retries (from agent config, default 2) |
|
||||
| LLM returns empty response | Treat as failure, retry |
|
||||
| LLM returns response > 200 words | Truncate to 200 words at sentence boundary |
|
||||
| All LLM retries exhausted | Fall back to deterministic template summary |
|
||||
| AgentConfigResolver returns None (agent not found) | Log error, use deterministic summary for all sections |
|
||||
| Chunk merge LLM call fails | Use concatenation of chunk summaries (joined with newlines) |
|
||||
|
||||
### Validation Edge Cases
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| Snapshot value is 0 and computed value is non-zero | Flag as warning with pct_difference = 100.0 |
|
||||
| Both snapshot and computed values are 0 | No warning (0% difference) |
|
||||
| Snapshot value is NULL | Skip validation for that metric, no warning |
|
||||
| Computed value is NaN or infinity | Replace with 0.0, log warning |
|
||||
| No prediction_outcomes to cross-reference | Skip recommendation accuracy validation entirely |
|
||||
|
||||
### Report Storage Failures
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| Unique constraint violation on insert | Use ON CONFLICT DO UPDATE to upsert |
|
||||
| JSONB serialization failure | Log error with report structure, propagate to job processor |
|
||||
| Report exceeds PostgreSQL JSONB size limit (~255 MB) | Extremely unlikely given report structure; log error if it occurs |
|
||||
|
||||
### Job Processing Failures
|
||||
|
||||
| Scenario | Handling |
|
||||
|----------|----------|
|
||||
| Job fails on first attempt | Retry with exponential backoff: 30s, 60s, 120s |
|
||||
| Job fails after 3 retries | Mark job as failed, log error with full context |
|
||||
| Duplicate job submitted for same period | Reject with log message, return without error |
|
||||
| Redis connection failure | Job stays in queue, picked up on reconnection |
|
||||
|
||||
---
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Property-Based Tests (Hypothesis)
|
||||
|
||||
Property-based tests use the Hypothesis library with `@settings(max_examples=100)`. Test files are prefixed `test_pbt_*` per project convention.
|
||||
|
||||
| Property | Test File | What It Tests |
|
||||
|----------|-----------|---------------|
|
||||
| Property 1: Chunking Round-Trip | `tests/test_pbt_report_chunking.py` | `chunk_data()` preserves content and respects size limits |
|
||||
| Property 2: Report Serialization Round-Trip | `tests/test_pbt_report_serialization.py` | `ReportData.model_dump_json()` → `ReportData.model_validate_json()` round-trip |
|
||||
| Property 3: Validation Discrepancy Detection | `tests/test_pbt_report_validation.py` | Discrepancy detection correctly flags >5% differences |
|
||||
| Property 4: Recommendation Accuracy Aggregation | `tests/test_pbt_report_sections.py` | `build_recommendation_accuracy_section()` computes correct aggregates |
|
||||
| Property 5: Portfolio Delta Computation | `tests/test_pbt_report_sections.py` | `build_pnl_section()` computes correct period-over-period deltas |
|
||||
|
||||
Each property test is tagged with a comment referencing the design property:
|
||||
```python
|
||||
# Feature: trading-feedback-engine, Property 1: Chunking round-trip and size constraint
|
||||
```
|
||||
|
||||
### Unit Tests (pytest)
|
||||
|
||||
| Test File | Coverage |
|
||||
|-----------|----------|
|
||||
| `tests/test_report_sections.py` | Section builders with known inputs, edge cases (empty data, single position, zero-activity) |
|
||||
| `tests/test_report_validator.py` | Specific discrepancy scenarios, boundary cases (exactly 5%), NULL snapshot values |
|
||||
| `tests/test_report_summarizer.py` | Deterministic fallback summary, chunk splitting edge cases (empty input, single char) |
|
||||
| `tests/test_report_models.py` | Pydantic model validation, enum constraints, default values |
|
||||
| `tests/test_report_generator.py` | Orchestration with mocked dependencies, zero-activity report, upsert behavior |
|
||||
|
||||
### Integration Tests
|
||||
|
||||
| Test File | Coverage |
|
||||
|-----------|----------|
|
||||
| `tests/test_report_api.py` | API endpoints with seeded database, pagination, filtering by report_type and date range |
|
||||
| `tests/test_report_storage.py` | Store/retrieve round-trip against real asyncpg pool, upsert behavior, unique constraint |
|
||||
|
||||
### Frontend Tests (Vitest)
|
||||
|
||||
| Test File | Coverage |
|
||||
|-----------|----------|
|
||||
| `frontend/src/test/reports.test.ts` | useReports and useReport hooks with MSW mocks, loading/error states |
|
||||
|
||||
### Test Configuration
|
||||
|
||||
- Python PBT: Hypothesis with `@settings(max_examples=100)`, files prefixed `test_pbt_*`
|
||||
- Python unit/integration: pytest with pytest-asyncio for async code
|
||||
- Frontend: Vitest with MSW for deterministic API mocking
|
||||
- Lint: `ruff check services/` before all commits
|
||||
- CI: Woodpecker runs all tests automatically on push to Gitea
|
||||
@@ -0,0 +1,117 @@
|
||||
# Requirements Document
|
||||
|
||||
## Introduction
|
||||
|
||||
The Trading Feedback Engine generates periodic performance reports from the Stonks Oracle trading system. Reports cover trading P&L, recommendation accuracy, position performance, risk metrics, and model quality trends. An AI agent (registered in the `ai_agents` table) summarizes sections of the report by processing data in small chunks that fit within the 8k-token context window. Reports are validated against live data from the prediction outcomes and model metric snapshots tables, stored in the database for retrieval, and exposed via API endpoints.
|
||||
|
||||
## Glossary
|
||||
|
||||
- **Feedback_Engine**: The backend service that orchestrates report generation, data collection, AI summarization, and report storage.
|
||||
- **Report_Summarizer_Agent**: The AI agent registered in the `ai_agents` table that generates natural-language summaries for report sections. Uses the existing `AgentConfigResolver` and `llm_factory` infrastructure.
|
||||
- **Report**: A structured JSON document containing trading performance metrics, AI-generated summaries, and validation data for a specific period (daily or weekly).
|
||||
- **Report_Section**: A self-contained portion of a report (e.g., P&L summary, recommendation accuracy, position performance) that can be independently generated and summarized.
|
||||
- **Chunk**: A subset of data rows small enough to fit within the 8k-token context window when serialized, allowing the Report_Summarizer_Agent to process it in a single LLM call.
|
||||
- **Portfolio_Snapshot**: A daily record in the `portfolio_snapshots` table containing portfolio value, pool balances, returns, win/loss counts, Sharpe ratio, max drawdown, and risk tier.
|
||||
- **Prediction_Outcome**: A record in the `prediction_outcomes` table containing realized returns, direction correctness, and excess returns vs benchmarks for a prediction at a specific horizon.
|
||||
- **Model_Metric_Snapshot**: A record in the `model_metric_snapshots` table containing aggregate model quality metrics (win rate, IC, ECE, Brier score) for a lookback/horizon combination.
|
||||
- **Trading_Decision**: A record in the `trading_decisions` table capturing the act/skip decision, skip reason, position sizing, risk tier, circuit breaker status, and decision trace for a recommendation evaluation.
|
||||
- **Validation_Data**: Live data from `prediction_outcomes`, `model_metric_snapshots`, and `signal_evidence_links` used to cross-check report claims against actual measured performance.
|
||||
- **Query_API**: The existing FastAPI service (`services/api/app.py`) that serves HTTP endpoints for the dashboard and external consumers.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement 1: Report Data Collection
|
||||
|
||||
**User Story:** As a trader, I want the feedback engine to collect all relevant trading data for a reporting period, so that reports reflect the complete picture of trading activity.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN a report generation is triggered for a date range, THE Feedback_Engine SHALL query trading_decisions, orders, positions, portfolio_snapshots, recommendations, prediction_outcomes, and model_metric_snapshots for that period.
|
||||
2. WHEN collecting trading decision data, THE Feedback_Engine SHALL include the decision type, skip reason, ticker, computed position size, risk tier, circuit breaker status, and correlation check result for each Trading_Decision.
|
||||
3. WHEN collecting portfolio data, THE Feedback_Engine SHALL retrieve the most recent Portfolio_Snapshot within the reporting period and compute period-over-period changes in portfolio value, active pool, reserve pool, and cumulative return.
|
||||
4. WHEN collecting recommendation accuracy data, THE Feedback_Engine SHALL join recommendations with Prediction_Outcomes to compute win rate, directional accuracy, and average excess return vs SPY for the period.
|
||||
5. IF no trading_decisions exist for the requested period, THEN THE Feedback_Engine SHALL generate a report with zero-activity sections and a note indicating no trading occurred.
|
||||
|
||||
### Requirement 2: Chunked AI Summarization
|
||||
|
||||
**User Story:** As a trader, I want AI-generated summaries in my reports, so that I can quickly understand performance trends without reading raw numbers.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Report_Summarizer_Agent SHALL be registered in the `ai_agents` table with slug `report-summarizer`, model `qwen3.5:9b-fast`, and source `system`.
|
||||
2. WHEN generating a summary for a Report_Section, THE Feedback_Engine SHALL serialize the section data into Chunks of no more than 6,000 characters each to stay within the 8k-token context window.
|
||||
3. WHEN a Report_Section contains data that exceeds a single Chunk, THE Feedback_Engine SHALL split the data into multiple Chunks, summarize each Chunk independently, and then produce a final merged summary from the individual Chunk summaries.
|
||||
4. WHEN invoking the Report_Summarizer_Agent, THE Feedback_Engine SHALL use the existing `AgentConfigResolver` and `llm_factory` infrastructure to resolve model configuration and build the LLM client.
|
||||
5. WHEN invoking the Report_Summarizer_Agent, THE Feedback_Engine SHALL log each invocation to the `agent_performance_log` table with agent_id, success status, duration_ms, and token estimates.
|
||||
6. IF the Report_Summarizer_Agent fails after max_retries, THEN THE Feedback_Engine SHALL fall back to a deterministic text summary built from the raw metrics and continue report generation.
|
||||
|
||||
### Requirement 3: Report Structure and Content
|
||||
|
||||
**User Story:** As a trader, I want reports to cover P&L, recommendation accuracy, position performance, risk metrics, and model quality, so that I have a comprehensive view of system performance.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Report SHALL contain a P&L section with realized P&L, unrealized P&L, daily return, cumulative return, win count, loss count, win rate, profit factor, and Sharpe ratio for the reporting period.
|
||||
2. THE Report SHALL contain a recommendation accuracy section with total recommendations evaluated, act/skip breakdown, win rate of acted-upon recommendations, and average confidence of acted vs skipped recommendations.
|
||||
3. THE Report SHALL contain a position performance section listing each position held during the period with ticker, entry price, current or exit price, unrealized or realized P&L, P&L percentage, and hold duration.
|
||||
4. THE Report SHALL contain a risk metrics section with current risk tier, portfolio heat, max drawdown, current drawdown percentage, reserve pool balance, and a count of circuit breaker events during the period.
|
||||
5. THE Report SHALL contain a model quality section with the latest Model_Metric_Snapshot values for win rate, directional accuracy, information coefficient, calibration error (ECE), and Brier score across the 7d, 30d, and 90d lookback windows.
|
||||
6. THE Report SHALL contain an AI-generated executive summary that synthesizes the key findings from all sections into a concise narrative of no more than 300 words.
|
||||
|
||||
### Requirement 4: Report Validation Against Live Data
|
||||
|
||||
**User Story:** As a trader, I want report metrics to be cross-checked against live validation data, so that I can trust the accuracy of the reported numbers.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. WHEN generating the recommendation accuracy section, THE Feedback_Engine SHALL cross-reference reported win rates with the `direction_correct` and `profitable` fields from Prediction_Outcomes for the same tickers and period.
|
||||
2. WHEN generating the model quality section, THE Feedback_Engine SHALL compare the reported metrics against the most recent Model_Metric_Snapshot records and flag discrepancies greater than 5% between computed and snapshot values.
|
||||
3. WHEN a validation discrepancy is detected, THE Feedback_Engine SHALL include a `validation_warnings` array in the report section with the field name, computed value, snapshot value, and percentage difference.
|
||||
4. THE Report SHALL include a `validation_status` field set to `passed` when no discrepancies exceed 5%, or `warnings` when one or more discrepancies are detected.
|
||||
|
||||
### Requirement 5: Report Storage and Retrieval
|
||||
|
||||
**User Story:** As a trader, I want reports stored in the database and accessible via API, so that I can review historical performance at any time.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Feedback_Engine SHALL store each generated Report as a row in a `trading_reports` table with columns for id (UUID), report_type (daily/weekly), period_start (DATE), period_end (DATE), report_data (JSONB), validation_status (VARCHAR), generated_at (TIMESTAMPTZ), and created_at (TIMESTAMPTZ).
|
||||
2. THE Feedback_Engine SHALL enforce a unique constraint on (report_type, period_start, period_end) to prevent duplicate reports for the same period.
|
||||
3. WHEN a report for an existing period is regenerated, THE Feedback_Engine SHALL update the existing row with the new report_data, validation_status, and generated_at timestamp.
|
||||
4. THE Query_API SHALL expose a `GET /api/reports` endpoint that returns a paginated list of reports with id, report_type, period_start, period_end, validation_status, and generated_at.
|
||||
5. THE Query_API SHALL expose a `GET /api/reports/{report_id}` endpoint that returns the full report including report_data JSONB.
|
||||
6. THE Query_API SHALL support filtering reports by report_type and date range via query parameters on the `GET /api/reports` endpoint.
|
||||
|
||||
### Requirement 6: Periodic Report Generation
|
||||
|
||||
**User Story:** As a trader, I want reports generated automatically on a daily and weekly schedule, so that I always have up-to-date performance feedback.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Feedback_Engine SHALL generate a daily report after market close (after 16:30 ET) covering the current trading day.
|
||||
2. THE Feedback_Engine SHALL generate a weekly report on Saturday covering the Monday-through-Friday trading week.
|
||||
3. WHEN a scheduled report generation is triggered, THE Feedback_Engine SHALL enqueue a report generation job on a Redis queue for asynchronous processing.
|
||||
4. IF a report generation job fails, THEN THE Feedback_Engine SHALL retry the job up to 3 times with exponential backoff before marking the job as failed.
|
||||
5. WHILE a report generation job is in progress for a given period, THE Feedback_Engine SHALL reject duplicate job submissions for the same report_type and period.
|
||||
|
||||
### Requirement 7: Agent Registration and Editability
|
||||
|
||||
**User Story:** As a trader, I want the report summarizer agent registered in the ai_agents table, so that I can edit its prompts, model, and parameters through the existing agent management API.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Feedback_Engine SHALL register the Report_Summarizer_Agent in the `ai_agents` table via a database migration with slug `report-summarizer`, source `system`, model_provider `ollama`, and model_name `qwen3.5:9b-fast`.
|
||||
2. THE Report_Summarizer_Agent system prompt SHALL instruct the model to produce concise financial performance summaries, avoid fabricating data not present in the input, and keep each summary under 200 words.
|
||||
3. THE Report_Summarizer_Agent SHALL support variant creation and activation through the existing agent variants system, allowing A/B testing of different summarization prompts.
|
||||
4. WHEN the Report_Summarizer_Agent configuration is updated via the agent management API, THE Feedback_Engine SHALL pick up the new configuration within 60 seconds via the `AgentConfigResolver` TTL cache.
|
||||
|
||||
### Requirement 8: Report Serialization Round-Trip
|
||||
|
||||
**User Story:** As a developer, I want report data to survive serialization and deserialization without data loss, so that stored reports are always faithful to the generated content.
|
||||
|
||||
#### Acceptance Criteria
|
||||
|
||||
1. THE Feedback_Engine SHALL serialize Report objects to JSON for storage in the `report_data` JSONB column.
|
||||
2. THE Feedback_Engine SHALL deserialize stored JSON back into Report objects for API responses.
|
||||
3. FOR ALL valid Report objects, serializing to JSON then deserializing back SHALL produce an equivalent Report object (round-trip property).
|
||||
4. THE Feedback_Engine SHALL use ISO 8601 format for all datetime fields in serialized reports.
|
||||
@@ -0,0 +1,195 @@
|
||||
# Implementation Plan: Trading Feedback Engine
|
||||
|
||||
## Overview
|
||||
|
||||
Add a periodic trading performance reporting system to Stonks Oracle. The system collects trading data, generates structured JSON reports with AI-powered summaries, validates metrics against live data, and stores reports for retrieval via API. Implementation follows the four-phase approach from the design: foundation → validation & AI → generator & API → scheduling & tests.
|
||||
|
||||
## Tasks
|
||||
|
||||
- [x] 1. Database migration 038 — trading_reports table and report-summarizer agent
|
||||
- [x] 1.1 Create `infra/migrations/038_trading_reports.sql`
|
||||
- Create `trading_reports` table with columns: id (UUID PK, gen_random_uuid()), report_type (VARCHAR(20) NOT NULL), period_start (DATE NOT NULL), period_end (DATE NOT NULL), report_data (JSONB NOT NULL), validation_status (VARCHAR(20) NOT NULL DEFAULT 'passed'), generated_at (TIMESTAMPTZ NOT NULL), created_at (TIMESTAMPTZ NOT NULL DEFAULT NOW())
|
||||
- Add UNIQUE constraint on (report_type, period_start, period_end)
|
||||
- Add CHECK constraint: report_type IN ('daily', 'weekly')
|
||||
- Create indexes: idx_trading_reports_type, idx_trading_reports_period, idx_trading_reports_generated
|
||||
- Seed Report_Summarizer_Agent into ai_agents table with slug 'report-summarizer', model_provider 'ollama', model_name 'qwen3.5:9b-fast', source 'system', temperature 0.0, max_tokens 1024, timeout_seconds 60, max_retries 2
|
||||
- Use WHERE NOT EXISTS guard on agent insert to be idempotent
|
||||
- _Requirements: 5.1, 5.2, 7.1, 7.2_
|
||||
|
||||
- [x] 1.2 Add `QUEUE_REPORT_GENERATION` constant to `services/shared/redis_keys.py`
|
||||
- Add `QUEUE_REPORT_GENERATION = "report_generation"` following existing queue naming convention
|
||||
- _Requirements: 6.3_
|
||||
|
||||
- [x] 2. Phase 1 — Report models, data collector, and section builders
|
||||
- [x] 2.1 Create report models (`services/reporting/models.py`)
|
||||
- Create `services/reporting/__init__.py`
|
||||
- Define enums: ReportType (daily, weekly), ValidationStatus (passed, warnings)
|
||||
- Define Pydantic models: ValidationWarning, PLSection, RecommendationAccuracySection, PositionDetail, PositionPerformanceSection, RiskMetricsSection, ModelQualityWindow, ModelQualitySection, ReportData
|
||||
- ReportData includes all sections, executive_summary, validation_status, generated_at, period_start, period_end, report_type
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 8.1, 8.2, 8.4_
|
||||
|
||||
- [x] 2.2 Implement data collector (`services/reporting/collector.py`)
|
||||
- Define CollectedData dataclass with fields: trading_decisions, orders, open_positions, closed_positions, portfolio_snapshot, previous_portfolio_snapshot, recommendations, prediction_outcomes, model_metric_snapshots, circuit_breaker_events, reserve_pool_balance
|
||||
- Implement `collect_report_data(pool, period_start, period_end)` → CollectedData
|
||||
- Query trading_decisions, orders, positions (open + closed), portfolio_snapshots (current + previous), recommendations, prediction_outcomes, model_metric_snapshots, circuit_breaker_events, reserve_pool_ledger for the period
|
||||
- Return empty lists for tables with no data (zero-activity case)
|
||||
- Use `_row_dict()` pattern for UUID conversion from asyncpg rows
|
||||
- _Requirements: 1.1, 1.2, 1.3, 1.4, 1.5_
|
||||
|
||||
- [x] 2.3 Implement section builders (`services/reporting/sections.py`)
|
||||
- Implement `build_pnl_section(data: CollectedData) -> PLSection` — compute realized/unrealized P&L, daily return, cumulative return, win/loss counts, win rate, profit factor, Sharpe ratio from portfolio_snapshot and closed positions
|
||||
- Implement `build_recommendation_accuracy_section(data: CollectedData) -> RecommendationAccuracySection` — join trading_decisions with prediction_outcomes, compute act/skip breakdown, win rate of acted, avg confidence acted vs skipped
|
||||
- Implement `build_position_performance_section(data: CollectedData) -> PositionPerformanceSection` — list each position with ticker, entry price, current/exit price, P&L, P&L%, hold duration
|
||||
- Implement `build_risk_metrics_section(data: CollectedData) -> RiskMetricsSection` — extract risk tier, portfolio heat, max drawdown, current drawdown %, reserve pool balance, circuit breaker event count
|
||||
- Implement `build_model_quality_section(data: CollectedData) -> ModelQualitySection` — extract model_metric_snapshot values for 7d, 30d, 90d lookback windows
|
||||
- Handle zero-activity gracefully (zero values, empty lists)
|
||||
- _Requirements: 1.3, 1.4, 3.1, 3.2, 3.3, 3.4, 3.5_
|
||||
|
||||
- [x] 3. Checkpoint — Verify foundation modules
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
- Run `.venv/bin/ruff check services/reporting/`
|
||||
- Run `.venv/bin/python -m pytest tests/ -x --tb=short -q -k "report"` to verify models and section builders
|
||||
|
||||
- [x] 4. Phase 2 — Report validator and AI summarizer
|
||||
- [x] 4.1 Implement report validator (`services/reporting/validator.py`)
|
||||
- Define `DISCREPANCY_THRESHOLD_PCT = 5.0`
|
||||
- Implement `validate_recommendation_accuracy(section, prediction_outcomes)` → list[ValidationWarning] — compare computed win rate against direction_correct/profitable from prediction_outcomes, flag >5% discrepancies
|
||||
- Implement `validate_model_quality(section, metric_snapshots)` → list[ValidationWarning] — compare reported metrics against model_metric_snapshots for win_rate, directional_accuracy, IC, ECE, Brier score, flag >5% discrepancies
|
||||
- Implement `compute_validation_status(report: ReportData)` → ValidationStatus — return 'passed' if no warnings, 'warnings' if any section has validation_warnings
|
||||
- Handle edge cases: snapshot=0 with computed≠0 → 100% difference; both=0 → no warning; snapshot=NULL → skip; computed=NaN → replace with 0.0
|
||||
- _Requirements: 4.1, 4.2, 4.3, 4.4_
|
||||
|
||||
- [x] 4.2 Implement AI summarizer (`services/reporting/summarizer.py`)
|
||||
- Define constants: CHUNK_SIZE_LIMIT=6000, MAX_SUMMARY_WORDS=200, MAX_EXECUTIVE_SUMMARY_WORDS=300
|
||||
- Implement `chunk_data(serialized: str, max_chars: int)` → list[str] — split on newline boundaries, each chunk ≤ max_chars, at least one chunk returned
|
||||
- Implement `summarize_section(pool, resolver, section_name, section_data)` → str — serialize, chunk if needed, summarize each chunk via Report_Summarizer_Agent (resolved by slug 'report-summarizer'), merge if multiple chunks, log to agent_performance_log, fall back to deterministic on failure
|
||||
- Implement `build_deterministic_summary(section_name, section_data)` → str — template-based fallback summary from raw metrics
|
||||
- Implement `generate_executive_summary(pool, resolver, section_summaries)` → str — concatenate section summaries, chunk if needed, produce ≤300-word synthesis, fall back to concatenation on failure
|
||||
- Use AgentConfigResolver + llm_factory for LLM access
|
||||
- Log each invocation to agent_performance_log with agent_id, success, duration_ms, token estimates
|
||||
- _Requirements: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 3.6_
|
||||
|
||||
- [x] 5. Checkpoint — Verify validator and summarizer
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
- Run `.venv/bin/ruff check services/reporting/`
|
||||
- Run `.venv/bin/python -m pytest tests/ -x --tb=short -q -k "report"` to verify validator and summarizer
|
||||
|
||||
- [x] 6. Phase 3 — Report generator orchestrator and API endpoints
|
||||
- [x] 6.1 Implement report generator (`services/reporting/generator.py`)
|
||||
- Implement `generate_report(pool, report_type, period_start, period_end)` → ReportData — orchestrate: collect data → build sections → validate → summarize → assemble ReportData
|
||||
- Implement `store_report(pool, report)` → str (UUID) — INSERT ... ON CONFLICT (report_type, period_start, period_end) DO UPDATE for upsert, return report id
|
||||
- Implement `process_report_job(pool, job: dict)` → None — deserialize job payload, call generate_report + store_report, handle retries with exponential backoff (30s, 60s, 120s up to 3 attempts), reject duplicate jobs for same report_type + period
|
||||
- _Requirements: 5.1, 5.2, 5.3, 6.3, 6.4, 6.5_
|
||||
|
||||
- [x] 6.2 Add API endpoints to `services/api/app.py`
|
||||
- Add `GET /api/reports` — paginated list with query params: report_type, start_date, end_date, limit (default 20), offset (default 0); returns id, report_type, period_start, period_end, validation_status, generated_at
|
||||
- Add `GET /api/reports/{report_id}` — full report including report_data JSONB
|
||||
- Use asyncpg pool from existing app state
|
||||
- Return 404 for non-existent report_id
|
||||
- _Requirements: 5.4, 5.5, 5.6_
|
||||
|
||||
- [x] 6.3 Add frontend hooks to `frontend/src/api/hooks.ts`
|
||||
- Add `ReportListItem` and `ReportDetail` TypeScript interfaces
|
||||
- Implement `useReports(params?)` hook — builds query string from report_type, start_date, end_date, limit, offset; uses `useGet` with 'query' base
|
||||
- Implement `useReport(id)` hook — fetches single report by id, enabled only when id is defined
|
||||
- _Requirements: 5.4, 5.5_
|
||||
|
||||
- [x] 7. Checkpoint — Verify generator and API
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
- Run `.venv/bin/ruff check services/`
|
||||
- Run `.venv/bin/python -m pytest tests/ -x --tb=short -q -k "report"` to verify generator and API endpoints
|
||||
|
||||
- [x] 8. Phase 4 — Scheduling, property-based tests, unit tests, and frontend tests
|
||||
- [x] 8.1 Wire Redis queue integration and scheduler
|
||||
- Add report generation job consumer to the scheduler service that listens on `stonks:queue:report_generation`
|
||||
- Add daily report trigger (after 16:30 ET on trading days) and weekly report trigger (Saturday) to the scheduler
|
||||
- Job payload: `{"report_type": "daily"|"weekly", "period_start": "YYYY-MM-DD", "period_end": "YYYY-MM-DD"}`
|
||||
- _Requirements: 6.1, 6.2, 6.3, 6.4, 6.5_
|
||||
|
||||
- [x] 8.2 Write property test: Chunking Round-Trip and Size Constraint
|
||||
- **Property 1: Chunking Round-Trip and Size Constraint**
|
||||
- File: `tests/test_pbt_report_chunking.py`
|
||||
- Use Hypothesis `@settings(max_examples=100)` with `@given(st.text())` and `@given(st.integers(min_value=1, max_value=10000))`
|
||||
- Assert: every chunk ≤ max_chars, no empty chunks (except empty input → one empty chunk), concatenation of chunks == original input
|
||||
- **Validates: Requirements 2.2**
|
||||
|
||||
- [x] 8.3 Write property test: Report Serialization Round-Trip
|
||||
- **Property 2: Report Serialization Round-Trip**
|
||||
- File: `tests/test_pbt_report_serialization.py`
|
||||
- Use Hypothesis with custom strategies for ReportData (valid PLSection, RecommendationAccuracySection, etc.)
|
||||
- Assert: `ReportData.model_validate_json(report.model_dump_json())` == original report
|
||||
- Assert: all datetime fields in serialized JSON are ISO 8601 format
|
||||
- **Validates: Requirements 8.1, 8.2, 8.3, 8.4**
|
||||
|
||||
- [x] 8.4 Write property test: Validation Discrepancy Detection Correctness
|
||||
- **Property 3: Validation Discrepancy Detection Correctness**
|
||||
- File: `tests/test_pbt_report_validation.py`
|
||||
- Use Hypothesis with `@given(st.floats(min_value=0, max_value=1e6), st.floats(min_value=0, max_value=1e6))`
|
||||
- Assert: warning iff |computed - snapshot| / snapshot * 100 > 5% (when snapshot > 0); flag any non-zero computed when snapshot == 0; no warning when both == 0
|
||||
- **Validates: Requirements 4.1, 4.2, 4.3, 4.4**
|
||||
|
||||
- [x] 8.5 Write property test: Recommendation Accuracy Aggregation
|
||||
- **Property 4: Recommendation Accuracy Aggregation**
|
||||
- File: `tests/test_pbt_report_sections.py`
|
||||
- Use Hypothesis with lists of trading decisions + prediction outcomes (direction_correct bool, profitable bool, excess_return_vs_spy float)
|
||||
- Assert: win_rate == count(profitable) / total, directional_accuracy == count(direction_correct) / total, avg excess return == mean(excess_return_vs_spy), all rates in [0.0, 1.0]
|
||||
- **Validates: Requirements 1.4**
|
||||
|
||||
- [x] 8.6 Write property test: Portfolio Period-Over-Period Delta Computation
|
||||
- **Property 5: Portfolio Period-Over-Period Delta Computation**
|
||||
- File: `tests/test_pbt_report_sections.py`
|
||||
- Use Hypothesis with two portfolio snapshots (non-negative portfolio_value, active_pool, reserve_pool, finite cumulative_return)
|
||||
- Assert: deltas == (current - previous) for each field; when no previous snapshot, deltas == 0
|
||||
- **Validates: Requirements 1.3**
|
||||
|
||||
- [x] 8.7 Write unit tests for section builders
|
||||
- File: `tests/test_report_sections.py`
|
||||
- Test each section builder with known inputs and expected outputs
|
||||
- Test edge cases: empty data (zero-activity), single position, no portfolio snapshot
|
||||
- _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5_
|
||||
|
||||
- [x] 8.8 Write unit tests for report validator
|
||||
- File: `tests/test_report_validator.py`
|
||||
- Test specific discrepancy scenarios: exactly 5% (no warning), 5.1% (warning), snapshot=0 computed≠0, both=0, NULL snapshot
|
||||
- _Requirements: 4.1, 4.2, 4.3, 4.4_
|
||||
|
||||
- [x] 8.9 Write unit tests for AI summarizer
|
||||
- File: `tests/test_report_summarizer.py`
|
||||
- Test deterministic fallback summary generation
|
||||
- Test chunk_data edge cases: empty input, single character, exactly at limit, one char over limit
|
||||
- _Requirements: 2.2, 2.6_
|
||||
|
||||
- [x] 8.10 Write unit tests for report generator
|
||||
- File: `tests/test_report_generator.py`
|
||||
- Test orchestration with mocked dependencies (collector, sections, validator, summarizer)
|
||||
- Test zero-activity report generation
|
||||
- Test upsert behavior (regeneration of existing report)
|
||||
- _Requirements: 5.1, 5.2, 5.3_
|
||||
|
||||
- [x] 8.11 Write API integration tests
|
||||
- File: `tests/test_report_api.py`
|
||||
- Test GET /api/reports with pagination, filtering by report_type and date range
|
||||
- Test GET /api/reports/{report_id} with valid and invalid IDs
|
||||
- _Requirements: 5.4, 5.5, 5.6_
|
||||
|
||||
- [x] 8.12 Write frontend hook tests
|
||||
- File: `frontend/src/test/reports.test.ts`
|
||||
- Test useReports and useReport hooks with MSW mocks
|
||||
- Test loading and error states
|
||||
- _Requirements: 5.4, 5.5_
|
||||
|
||||
- [x] 9. Final checkpoint — Full test suite and lint
|
||||
- Ensure all tests pass, ask the user if questions arise.
|
||||
- Run `.venv/bin/ruff check services/`
|
||||
- Run `.venv/bin/python -m pytest tests/ -x --tb=short -q -k "report"`
|
||||
- Run frontend tests: `cd frontend && npx vitest --run`
|
||||
|
||||
## Notes
|
||||
|
||||
- Tasks marked with `*` are optional and can be skipped for faster MVP
|
||||
- Each task references specific requirements for traceability
|
||||
- Checkpoints ensure incremental validation after each phase
|
||||
- Property tests validate the 5 universal correctness properties from the design document
|
||||
- Unit tests validate specific examples and edge cases
|
||||
- The design document contains full interface signatures — use those as the implementation guide
|
||||
- Always run `.venv/bin/ruff check services/` before committing Python changes
|
||||
@@ -35,12 +35,22 @@
|
||||
- Push to Gitea: `git push gitea main`
|
||||
- Gitea remote: `http://admin:<password>@10.1.1.12:30300/admin/stonks-oracle.git`
|
||||
- Pipeline stages: lint → pytest → frontend vitest → build all service images + dashboard + superset → push to Harbor
|
||||
- Build pipelines split across `build-1.yml`, `build-2.yml`, `build-3.yml` for parallelism
|
||||
- ArgoCD watches Gitea `main` and auto-syncs beta/paper/live stages
|
||||
- **Do NOT push directly to GitHub** — GitHub is the promotion target after CI passes
|
||||
- Once Woodpecker builds and tests pass, code is promoted to GitHub (`git push origin main`)
|
||||
- CI handles all image builds and pushes — do NOT manually docker push
|
||||
- Check Woodpecker CI status from the Gitea web UI or Woodpecker dashboard
|
||||
|
||||
### Dashboard Build (npm ci in K8s)
|
||||
- `build-3.yml` has a `npm-install-dashboard` step that runs `npm ci` in a `node:24-alpine` pod
|
||||
- K8s CoreDNS causes `EAI_AGAIN` errors for Node.js under concurrent DNS lookups
|
||||
- Fix: the step resolves `registry.npmjs.org` to IPv4 via Google DoH and pins it in `/etc/hosts`
|
||||
- `NODE_OPTIONS=--dns-result-order=ipv4first` env var is set as additional safety
|
||||
- `frontend/.dockerignore` must NOT exclude `node_modules` — the Dockerfile expects it pre-staged
|
||||
- The subsequent `build-dashboard` step uses `frontend/` as Docker context (includes `node_modules`)
|
||||
- If `npm ci` hangs: check `/etc/hosts` pinning worked, check `npm config set loglevel http` for which request is stuck
|
||||
|
||||
## Deploy
|
||||
- Full deploy/redeploy: `bash ~/sources/kube/stonks-oracle/runmefirst.sh` (from gremlin-1)
|
||||
- Full teardown: `bash ~/sources/kube/stonks-oracle/runmelast.sh` (from gremlin-1)
|
||||
@@ -93,8 +103,40 @@ Ingestion jobs MUST include `source_id`, `source_type`, `ticker`, `company_id`,
|
||||
- The `competitor_relationships` table uses UUID company IDs — queries must join through `companies` to match by ticker
|
||||
- The dashboard Docker build uses TypeScript strict mode — unused imports that pass local diagnostics will fail in CI
|
||||
- Ingestion jobs require `source_id` from the `sources` table — don't just pass `ticker`
|
||||
- `frontend/.dockerignore` must NOT contain `node_modules` — the CI pre-installs it and the Dockerfile relies on `COPY . .` including it
|
||||
- `npm config set prefer-ip-address-family 4` does NOT exist in npm 10.x (Node 24) — don't use it
|
||||
- Woodpecker `environment:` uses map syntax (`KEY: "value"`) not list syntax (`- KEY=value`)
|
||||
- Node.js in Alpine K8s pods gets `EAI_AGAIN` from CoreDNS under load — pin hostnames in `/etc/hosts` for reliability
|
||||
- Every Helm-deployed service MUST have a corresponding image build step in `.woodpecker/build-*.yml`
|
||||
- **Bash `!` in passwords/strings**: Bash interprets `!` inside double quotes as history expansion. NEVER use double quotes around strings containing `!`. Use single quotes instead: `'St0nks0racl3!'`. For kubectl exec with psql, use: `kubectl exec ... -- psql -U postgres -c "ALTER USER x WITH PASSWORD '"'"'password!'"'"';"` (single-quote escaping trick)
|
||||
|
||||
## No Premature Simplification
|
||||
Do NOT "simplify" code on impulse. When the urge arises to simplify a section, STOP and do this instead:
|
||||
|
||||
1. **Evaluate the section**: Read the full function/module, not just the part that looks complex.
|
||||
2. **Map the dependencies**: Identify every caller, every consumer, every downstream component that depends on this code's behavior, return shape, or side effects.
|
||||
3. **Assess blast radius**: Would changing this function break other implementations? Check imports, tests, API contracts, database queries, and frontend expectations.
|
||||
4. **Respect intentional complexity**: If the code is complex because the domain is complex (financial math, multi-layer signal aggregation, Bayesian shrinkage), the complexity is load-bearing. Simplifying it will introduce bugs.
|
||||
5. **Only simplify when**: The complexity is accidental (dead code, redundant branches, copy-paste artifacts) AND you have confirmed no downstream dependencies break.
|
||||
|
||||
This codebase has interconnected layers (ingestion → extraction → aggregation → recommendation → trading → validation). A "simple" change to a scoring function can cascade through trend summaries, recommendations, snapshot capture, and outcome evaluation. Always trace the full path before refactoring.
|
||||
|
||||
## Documentation
|
||||
- Do NOT create large summary/success markdown files after each step
|
||||
- Keep notes short, concise, and organized under `docs/notes/`
|
||||
- If a note isn't useful for future reference, don't write it
|
||||
|
||||
## Documentation Maintenance on Feature Changes
|
||||
When implementing a feature or fix that introduces an impactful change, update the relevant documentation as part of the same commit or task. "Impactful" means any change that affects how someone installs, deploys, configures, operates, or understands the system. Specifically:
|
||||
|
||||
- **New database migrations**: Update `docs/architecture-data-pipeline.md` or `docs/api-reference.md` if new tables, views, or endpoints are added. Update `project-context.md` steering file with the new migration number.
|
||||
- **New API endpoints**: Update `docs/api-reference.md` with the endpoint path, method, parameters, and response shape.
|
||||
- **New services or service changes**: Update `docs/architecture-docker-compose.md` and `docs/docker-deployment.md` if a new service is added or an existing service's configuration changes.
|
||||
- **Helm chart changes**: Update `docs/helm-reference.md` if new values, services, or config options are added.
|
||||
- **New environment variables or secrets**: Update `docs/LOCAL_DEV_SETUP.md` and the project-context steering file.
|
||||
- **Install/deploy script changes**: Update `deploy-docker.sh`, `docs/docker-deployment.md`, or the relevant runme scripts if the deploy process changes.
|
||||
- **Frontend route or page additions**: Update `docs/api-reference.md` (if it covers UI routes) and ensure the nav item is documented.
|
||||
- **README.md**: Update the top-level `README.md` when a major new capability is added (new signal layer, new dashboard section, new trading feature).
|
||||
- **Steering files**: Update `.kiro/steering/project-context.md` when migration numbers advance, new services are added, or key conventions change.
|
||||
|
||||
The goal is that someone reading the docs can always understand the current state of the system without reading the source code. When in doubt, update the doc.
|
||||
|
||||
@@ -46,12 +46,20 @@ Three-layer signal aggregation engine:
|
||||
- Pipeline stages: lint → pytest → frontend vitest → build all service images + dashboard + superset → push to Harbor
|
||||
- Images tagged as `registry.celestium.life/stonks-oracle/<service>:<sha>` and `:latest`
|
||||
- Dashboard image: `frontend/Dockerfile` (multi-stage: node:24 → nginx-unprivileged on port 8080)
|
||||
- Dashboard build: `npm-install-dashboard` step in `build-3.yml` pre-installs `node_modules`, then `build-dashboard` runs the Docker build with `node_modules` in context
|
||||
- Superset image: `docker/Dockerfile.superset` (apache/superset + trino + psycopg2)
|
||||
- Python service images: `docker/Dockerfile` with `SERVICE_CMD` build arg
|
||||
- Specialist image: built in `build-3.yml` like other Python services (`SERVICE_CMD=uvicorn services.specialist.app:app --host 0.0.0.0 --port 8000`)
|
||||
- Let CI handle image builds and pushes — do NOT manually `docker build && docker push`
|
||||
- **Do NOT push directly to GitHub** — GitHub (`origin`) is the promotion target after CI builds and tests pass
|
||||
- Promotion to GitHub: `git push origin main` (only after Woodpecker CI succeeds)
|
||||
|
||||
### CI DNS Workaround (npm)
|
||||
- K8s CoreDNS causes `EAI_AGAIN` (temporary DNS failure) for Node.js/libuv under concurrent requests
|
||||
- Fix: `npm-install-dashboard` step resolves `registry.npmjs.org` via Google DoH (`dns.google/resolve`) and pins the IPv4 address in `/etc/hosts` before running `npm ci`
|
||||
- `NODE_OPTIONS=--dns-result-order=ipv4first` is set as env var (belt-and-suspenders)
|
||||
- `frontend/.dockerignore` does NOT exclude `node_modules` (it must be in the Docker build context since the Dockerfile has no `RUN npm ci`)
|
||||
|
||||
## Deployment Scripts
|
||||
- `~/sources/kube/stonks-oracle/runmefirst.sh` — full deploy: DB setup, migrations, Helm install, rolling restart (runs from gremlin-1 at 192.168.42.254 where secrets are available)
|
||||
- `~/sources/kube/stonks-oracle/runmelast.sh` — teardown: Helm uninstall, clean resources (preserves DB/MinIO/Redis)
|
||||
@@ -81,13 +89,14 @@ When a full reset is needed:
|
||||
## Database Migrations
|
||||
- Located in `infra/migrations/001_*.sql` through `030_*.sql`
|
||||
- Applied automatically by `runmefirst.sh` in sorted order
|
||||
- Next migration number: **031**
|
||||
- Next migration number: **038**
|
||||
- Key migrations:
|
||||
- 016: Global news interpolation (global_events, macro_impact_records, exposure_profiles, trend_projections)
|
||||
- 017: Competitive intelligence (competitor_relationships, competitive_signal_records)
|
||||
- 024: Trend history time-series table
|
||||
- 026: AI agents management (ai_agents, agent_performance_log)
|
||||
- 027: Agent variants (agent_variants table for A/B testing)
|
||||
- 035: Model validation (prediction_snapshots, prediction_outcomes, signal_evidence_links, model_metric_snapshots, v_prediction_performance, v_source_performance)
|
||||
|
||||
## Key Conventions
|
||||
- All services use `services/shared/config.py` for configuration via env vars
|
||||
|
||||
+49
-11
@@ -3,6 +3,11 @@ depends_on:
|
||||
when:
|
||||
event: push
|
||||
branch: main
|
||||
clone:
|
||||
git:
|
||||
image: woodpeckerci/plugin-git
|
||||
settings:
|
||||
remote: http://10.43.73.77:3000/admin/stonks-oracle.git
|
||||
steps:
|
||||
build-scheduler:
|
||||
image: woodpeckerci/plugin-docker-buildx
|
||||
@@ -10,11 +15,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/scheduler
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -45,11 +56,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/symbol-registry
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -63,8 +80,11 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=uvicorn services.symbol_registry.app:app --host 0.0.0.0 --port 8000
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=uvicorn services.symbol_registry.app:app --host 0.0.0.0 --port 8000
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
@@ -81,11 +101,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/ingestion
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -99,8 +125,11 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=python -m services.ingestion.worker
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=python -m services.ingestion.worker
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
@@ -117,11 +146,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/parser
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -135,8 +170,11 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=python -m services.parser.worker
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=python -m services.parser.worker
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
|
||||
+98
-12
@@ -3,6 +3,11 @@ depends_on:
|
||||
when:
|
||||
event: push
|
||||
branch: main
|
||||
clone:
|
||||
git:
|
||||
image: woodpeckerci/plugin-git
|
||||
settings:
|
||||
remote: http://10.43.73.77:3000/admin/stonks-oracle.git
|
||||
steps:
|
||||
build-extractor:
|
||||
image: woodpeckerci/plugin-docker-buildx
|
||||
@@ -10,11 +15,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/extractor
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -28,8 +39,11 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=python -m services.extractor.worker
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=python -m services.extractor.worker
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
@@ -46,11 +60,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/aggregation
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -64,8 +84,11 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=python -m services.aggregation.worker
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=python -m services.aggregation.worker
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
@@ -82,11 +105,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/recommendation
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -100,8 +129,56 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=python -m services.recommendation.worker
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=python -m services.recommendation.worker
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
requests:
|
||||
memory: 1Gi
|
||||
cpu: 1000m
|
||||
limits:
|
||||
memory: 2Gi
|
||||
cpu: 4000m
|
||||
depends_on: []
|
||||
build-signal-engine:
|
||||
image: woodpeckerci/plugin-docker-buildx
|
||||
privileged: true
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/signal-engine
|
||||
registry: registry.celestium.life
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
logins:
|
||||
- registry: https://registry.celestium.life
|
||||
username:
|
||||
from_secret: harbor_username
|
||||
password:
|
||||
from_secret: harbor_password
|
||||
tags:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=python -m services.signal_engine.main
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
@@ -118,11 +195,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/risk
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -136,8 +219,11 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=uvicorn services.risk.app:app --host 0.0.0.0 --port 8000
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=uvicorn services.risk.app:app --host 0.0.0.0 --port 8000
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
|
||||
+141
-17
@@ -3,6 +3,11 @@ depends_on:
|
||||
when:
|
||||
event: push
|
||||
branch: main
|
||||
clone:
|
||||
git:
|
||||
image: woodpeckerci/plugin-git
|
||||
settings:
|
||||
remote: http://10.43.73.77:3000/admin/stonks-oracle.git
|
||||
steps:
|
||||
build-broker-adapter:
|
||||
image: woodpeckerci/plugin-docker-buildx
|
||||
@@ -10,11 +15,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/broker-adapter
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -28,8 +39,11 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=python -m services.adapters.broker_adapter
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=python -m services.adapters.broker_adapter
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
@@ -46,11 +60,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/lake-publisher
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -64,8 +84,11 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=python -m services.lake_publisher.worker
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=python -m services.lake_publisher.worker
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
@@ -82,11 +105,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/query-api
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -100,8 +129,11 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=uvicorn services.api.app:app --host 0.0.0.0 --port 8000
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=uvicorn services.api.app:app --host 0.0.0.0 --port 8000
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
@@ -118,11 +150,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/trading-engine
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -136,8 +174,81 @@ steps:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args: SERVICE_CMD=uvicorn services.trading.app:app --host 0.0.0.0 --port 8000
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=uvicorn services.trading.app:app --host 0.0.0.0 --port 8000
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
requests:
|
||||
memory: 1Gi
|
||||
cpu: 1000m
|
||||
limits:
|
||||
memory: 2Gi
|
||||
cpu: 4000m
|
||||
depends_on: []
|
||||
build-specialist:
|
||||
image: woodpeckerci/plugin-docker-buildx
|
||||
privileged: true
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/specialist
|
||||
registry: registry.celestium.life
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
logins:
|
||||
- registry: https://registry.celestium.life
|
||||
username:
|
||||
from_secret: harbor_username
|
||||
password:
|
||||
from_secret: harbor_password
|
||||
tags:
|
||||
- ${CI_COMMIT_SHA}
|
||||
- latest
|
||||
dockerfile: docker/Dockerfile
|
||||
no_cache: true
|
||||
context: .
|
||||
build_args:
|
||||
- CACHE_BUST=${CI_COMMIT_SHA}
|
||||
- SERVICE_CMD=uvicorn services.specialist.app:app --host 0.0.0.0 --port 8000
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
requests:
|
||||
memory: 1Gi
|
||||
cpu: 1000m
|
||||
limits:
|
||||
memory: 2Gi
|
||||
cpu: 4000m
|
||||
depends_on: []
|
||||
npm-install-dashboard:
|
||||
image: registry.celestium.life/dockerhub-cache/library/node:24-alpine
|
||||
environment:
|
||||
NODE_OPTIONS: "--dns-result-order=ipv4first"
|
||||
commands:
|
||||
- echo "=== Pinning registry.npmjs.org to IPv4 in /etc/hosts ==="
|
||||
- REGISTRY_IP=$(wget -4 -q -O- https://dns.google/resolve?name=registry.npmjs.org\&type=A 2>/dev/null | sed -n 's/.*"data":"\([0-9.]*\)".*/\1/p' | head -1)
|
||||
- echo "Resolved registry.npmjs.org to $REGISTRY_IP"
|
||||
- if [ -n "$REGISTRY_IP" ]; then echo "$REGISTRY_IP registry.npmjs.org" >> /etc/hosts; else echo "104.16.1.35 registry.npmjs.org" >> /etc/hosts; fi
|
||||
- cat /etc/hosts
|
||||
- echo "=== npm/node versions ==="
|
||||
- node --version
|
||||
- npm --version
|
||||
- echo "=== Starting npm ci ==="
|
||||
- cd frontend && npm ci
|
||||
backend_options:
|
||||
kubernetes:
|
||||
resources:
|
||||
@@ -154,11 +265,17 @@ steps:
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/dashboard
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
@@ -183,18 +300,25 @@ steps:
|
||||
limits:
|
||||
memory: 2Gi
|
||||
cpu: 4000m
|
||||
depends_on: []
|
||||
depends_on:
|
||||
- npm-install-dashboard
|
||||
build-superset:
|
||||
image: woodpeckerci/plugin-docker-buildx
|
||||
privileged: true
|
||||
settings:
|
||||
repo: registry.celestium.life/stonks-oracle/superset
|
||||
registry: registry.celestium.life
|
||||
custom_dns: 192.168.42.1
|
||||
buildx_image: registry.celestium.life/dockerhub-cache/moby/buildkit:buildx-stable-1
|
||||
add_host: registry.celestium.life:10.1.1.12
|
||||
buildx_flags: --driver-opt network=host
|
||||
buildkitd_config: "[registry.\"docker.io\"]\n mirrors = [\"registry.celestium.life/v2/dockerhub-cache\"]\n[registry.\"ghcr.io\"]\n mirrors = [\"registry.celestium.life/v2/ghcr-cache\"]\n"
|
||||
insecure: true
|
||||
buildkit_config: |
|
||||
[registry."registry.celestium.life"]
|
||||
insecure = true
|
||||
[registry."docker.io"]
|
||||
mirrors = ["registry.celestium.life/v2/dockerhub-cache"]
|
||||
[registry."ghcr.io"]
|
||||
mirrors = ["registry.celestium.life/v2/ghcr-cache"]
|
||||
http_proxy: ""
|
||||
https_proxy: ""
|
||||
no_proxy: ""
|
||||
|
||||
@@ -8,6 +8,12 @@ when:
|
||||
event: push
|
||||
branch: main
|
||||
|
||||
clone:
|
||||
git:
|
||||
image: woodpeckerci/plugin-git
|
||||
settings:
|
||||
remote: http://10.43.73.77:3000/admin/stonks-oracle.git
|
||||
|
||||
steps:
|
||||
integration-test:
|
||||
image: registry.celestium.life/dockerhub-cache/alpine/k8s:1.30.2
|
||||
|
||||
@@ -2,6 +2,11 @@ when:
|
||||
event:
|
||||
- push
|
||||
- pull_request
|
||||
clone:
|
||||
git:
|
||||
image: woodpeckerci/plugin-git
|
||||
settings:
|
||||
remote: http://10.43.73.77:3000/admin/stonks-oracle.git
|
||||
steps:
|
||||
lint-python:
|
||||
image: registry.celestium.life/dockerhub-cache/library/python:3.12-slim
|
||||
|
||||
Executable
+518
@@ -0,0 +1,518 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
# deploy-docker.sh — Deploy Stonks Oracle to a Docker host via SSH
|
||||
#
|
||||
# Usage: bash deploy-docker.sh [OPTIONS]
|
||||
#
|
||||
# Options:
|
||||
# --host USER@HOST SSH target (default: celes@192.168.42.254)
|
||||
# --ollama-url URL Ollama API URL (default: auto-detect or install)
|
||||
# --ollama-model MODEL Ollama model name (default: qwen3.5:9b-fast)
|
||||
# --dir PATH Remote install directory (default: ~/stonks-oracle)
|
||||
#
|
||||
# Examples:
|
||||
# bash deploy-docker.sh
|
||||
# bash deploy-docker.sh --ollama-url http://10.1.1.12:2701 --ollama-model qwen3.6
|
||||
# bash deploy-docker.sh --host user@myserver --dir /opt/stonks
|
||||
|
||||
# -------------------------------------------------------
|
||||
# Configuration (override via flags or environment)
|
||||
# -------------------------------------------------------
|
||||
REMOTE_HOST="${DEPLOY_HOST:-celes@192.168.42.254}"
|
||||
REMOTE_DIR="${DEPLOY_DIR:-/home/celes/stonks-oracle}"
|
||||
OLLAMA_URL="${DEPLOY_OLLAMA_URL:-}"
|
||||
OLLAMA_MODEL="${DEPLOY_OLLAMA_MODEL:-qwen3.5:9b-fast}"
|
||||
REPO_URL="http://admin:St0nks0racl3!@10.1.1.12:30300/admin/stonks-oracle.git"
|
||||
|
||||
# Parse command-line flags
|
||||
while [[ $# -gt 0 ]]; do
|
||||
case $1 in
|
||||
--host) REMOTE_HOST="$2"; shift 2 ;;
|
||||
--ollama-url) OLLAMA_URL="$2"; shift 2 ;;
|
||||
--ollama-model) OLLAMA_MODEL="$2"; shift 2 ;;
|
||||
--dir) REMOTE_DIR="$2"; shift 2 ;;
|
||||
*) echo "Unknown option: $1"; exit 1 ;;
|
||||
esac
|
||||
done
|
||||
|
||||
echo "=== Stonks Oracle Docker Deployment ==="
|
||||
echo " Target: ${REMOTE_HOST}:${REMOTE_DIR}"
|
||||
echo " Model: ${OLLAMA_MODEL}"
|
||||
echo " Ollama: Docker container (GPU-accelerated)"
|
||||
echo ""
|
||||
|
||||
# -------------------------------------------------------
|
||||
# Step 0: Ensure prerequisites (multi-distro support)
|
||||
# -------------------------------------------------------
|
||||
echo "--- Step 0: Checking prerequisites ---"
|
||||
ssh "$REMOTE_HOST" bash -s <<'REMOTE_SCRIPT'
|
||||
set -euo pipefail
|
||||
|
||||
# --- Detect OS and package manager ---
|
||||
detect_os() {
|
||||
if [ -f /etc/os-release ]; then
|
||||
. /etc/os-release
|
||||
OS_ID="${ID:-unknown}"
|
||||
OS_LIKE="${ID_LIKE:-$OS_ID}"
|
||||
elif [ -f /etc/redhat-release ]; then
|
||||
OS_ID="rhel"
|
||||
OS_LIKE="rhel"
|
||||
else
|
||||
OS_ID="unknown"
|
||||
OS_LIKE="unknown"
|
||||
fi
|
||||
|
||||
# Detect WSL
|
||||
IS_WSL=false
|
||||
if grep -qi microsoft /proc/version 2>/dev/null; then
|
||||
IS_WSL=true
|
||||
fi
|
||||
|
||||
# Determine package manager
|
||||
if command -v apt-get &>/dev/null; then
|
||||
PKG_MGR="apt"
|
||||
elif command -v dnf &>/dev/null; then
|
||||
PKG_MGR="dnf"
|
||||
elif command -v yum &>/dev/null; then
|
||||
PKG_MGR="yum"
|
||||
elif command -v pacman &>/dev/null; then
|
||||
PKG_MGR="pacman"
|
||||
elif command -v zypper &>/dev/null; then
|
||||
PKG_MGR="zypper"
|
||||
else
|
||||
PKG_MGR="unknown"
|
||||
fi
|
||||
|
||||
echo " Detected: OS=$OS_ID (like=$OS_LIKE), pkg=$PKG_MGR, WSL=$IS_WSL"
|
||||
}
|
||||
|
||||
install_pkg() {
|
||||
local pkg="$1"
|
||||
case "$PKG_MGR" in
|
||||
apt) sudo apt-get install -y "$pkg" ;;
|
||||
dnf) sudo dnf -y install "$pkg" ;;
|
||||
yum) sudo yum -y install "$pkg" ;;
|
||||
pacman) sudo pacman -S --noconfirm "$pkg" ;;
|
||||
zypper) sudo zypper install -y "$pkg" ;;
|
||||
*) echo " ERROR: Unknown package manager"; exit 1 ;;
|
||||
esac
|
||||
}
|
||||
|
||||
update_pkg_cache() {
|
||||
case "$PKG_MGR" in
|
||||
apt) sudo apt-get update -qq ;;
|
||||
dnf|yum) ;; # dnf/yum auto-refresh
|
||||
pacman) sudo pacman -Sy ;;
|
||||
zypper) sudo zypper refresh -q ;;
|
||||
esac
|
||||
}
|
||||
|
||||
detect_os
|
||||
|
||||
# --- Git ---
|
||||
if ! command -v git &>/dev/null; then
|
||||
echo " Installing git..."
|
||||
update_pkg_cache
|
||||
install_pkg git
|
||||
echo " ✓ Git installed"
|
||||
else
|
||||
echo " ✓ Git present"
|
||||
fi
|
||||
|
||||
# --- Docker Engine ---
|
||||
if command -v docker &>/dev/null && docker info &>/dev/null; then
|
||||
echo " ✓ Docker already installed ($(docker --version | cut -d' ' -f3 | tr -d ','))"
|
||||
else
|
||||
echo " Installing Docker CE..."
|
||||
case "$PKG_MGR" in
|
||||
apt)
|
||||
# Debian/Ubuntu/WSL
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y ca-certificates curl gnupg
|
||||
sudo install -m 0755 -d /etc/apt/keyrings
|
||||
curl -fsSL https://download.docker.com/linux/${OS_ID}/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg 2>/dev/null
|
||||
sudo chmod a+r /etc/apt/keyrings/docker.gpg
|
||||
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/${OS_ID} $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
|
||||
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
|
||||
;;
|
||||
dnf|yum)
|
||||
# RHEL/Rocky/Fedora/CentOS
|
||||
sudo "$PKG_MGR" -y install dnf-plugins-core 2>/dev/null || true
|
||||
local repo_distro="rhel"
|
||||
if [[ "$OS_ID" == "fedora" ]]; then repo_distro="fedora"; fi
|
||||
sudo dnf config-manager --add-repo "https://download.docker.com/linux/${repo_distro}/docker-ce.repo" 2>/dev/null || \
|
||||
sudo yum-config-manager --add-repo "https://download.docker.com/linux/${repo_distro}/docker-ce.repo" 2>/dev/null
|
||||
sudo "$PKG_MGR" -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
|
||||
;;
|
||||
pacman)
|
||||
# Arch Linux
|
||||
sudo pacman -S --noconfirm docker docker-compose docker-buildx
|
||||
;;
|
||||
zypper)
|
||||
# openSUSE
|
||||
sudo zypper install -y docker docker-compose docker-buildx
|
||||
;;
|
||||
esac
|
||||
sudo systemctl enable --now docker 2>/dev/null || true
|
||||
sudo usermod -aG docker "$(whoami)" 2>/dev/null || true
|
||||
echo " ✓ Docker installed and started"
|
||||
fi
|
||||
|
||||
# --- Docker Compose plugin ---
|
||||
if docker compose version &>/dev/null; then
|
||||
echo " ✓ Docker Compose plugin available ($(docker compose version --short))"
|
||||
else
|
||||
echo " ERROR: docker compose plugin not found after Docker install"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# --- NVIDIA Driver (skip on WSL — uses host driver) ---
|
||||
if [ "$IS_WSL" = "true" ]; then
|
||||
echo " ✓ WSL detected — using host Windows NVIDIA driver"
|
||||
elif ! command -v nvidia-smi &>/dev/null; then
|
||||
echo " Installing NVIDIA drivers..."
|
||||
case "$PKG_MGR" in
|
||||
apt)
|
||||
sudo apt-get install -y nvidia-driver-560 2>/dev/null || \
|
||||
sudo apt-get install -y nvidia-driver 2>/dev/null || \
|
||||
echo " ⚠ NVIDIA driver install failed — install manually"
|
||||
;;
|
||||
dnf|yum)
|
||||
sudo dnf -y install epel-release 2>/dev/null || true
|
||||
sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/rhel9/x86_64/cuda-rhel9.repo 2>/dev/null || true
|
||||
sudo dnf -y module install nvidia-driver:latest-dkms 2>/dev/null || \
|
||||
echo " ⚠ NVIDIA driver install failed — install manually"
|
||||
;;
|
||||
pacman)
|
||||
sudo pacman -S --noconfirm nvidia nvidia-utils 2>/dev/null || \
|
||||
echo " ⚠ NVIDIA driver install failed — install manually"
|
||||
;;
|
||||
zypper)
|
||||
echo " ⚠ NVIDIA driver: install manually for openSUSE"
|
||||
;;
|
||||
esac
|
||||
else
|
||||
echo " ✓ NVIDIA driver present ($(nvidia-smi --query-gpu=driver_version --format=csv,noheader | head -1))"
|
||||
fi
|
||||
|
||||
# --- NVIDIA Container Toolkit ---
|
||||
if command -v nvidia-ctk &>/dev/null; then
|
||||
echo " ✓ NVIDIA Container Toolkit already installed"
|
||||
elif [ "$IS_WSL" = "true" ] && docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi &>/dev/null 2>&1; then
|
||||
echo " ✓ WSL GPU passthrough working (no nvidia-ctk needed)"
|
||||
else
|
||||
echo " Installing NVIDIA Container Toolkit..."
|
||||
case "$PKG_MGR" in
|
||||
apt)
|
||||
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg 2>/dev/null
|
||||
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
|
||||
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
|
||||
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list > /dev/null
|
||||
sudo apt-get update -qq
|
||||
sudo apt-get install -y nvidia-container-toolkit
|
||||
;;
|
||||
dnf|yum)
|
||||
curl -fsSL https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | \
|
||||
sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo > /dev/null
|
||||
sudo "$PKG_MGR" -y install nvidia-container-toolkit
|
||||
;;
|
||||
pacman)
|
||||
sudo pacman -S --noconfirm nvidia-container-toolkit 2>/dev/null || \
|
||||
echo " ⚠ Install nvidia-container-toolkit from AUR"
|
||||
;;
|
||||
zypper)
|
||||
echo " ⚠ NVIDIA Container Toolkit: install manually for openSUSE"
|
||||
;;
|
||||
esac
|
||||
sudo nvidia-ctk runtime configure --runtime=docker 2>/dev/null || true
|
||||
sudo systemctl restart docker 2>/dev/null || true
|
||||
echo " ✓ NVIDIA Container Toolkit installed and Docker configured"
|
||||
fi
|
||||
|
||||
# --- Verify GPU is accessible from Docker ---
|
||||
if docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi &>/dev/null 2>&1; then
|
||||
echo " ✓ GPU passthrough verified"
|
||||
else
|
||||
echo " ⚠ GPU passthrough test failed — may need a reboot or manual NVIDIA setup"
|
||||
fi
|
||||
|
||||
# --- Firewall (open required ports if firewall is active) ---
|
||||
if command -v firewall-cmd &>/dev/null && systemctl is-active firewalld &>/dev/null; then
|
||||
echo " Configuring firewalld..."
|
||||
for port in 3000 8001 8002 8003 8004 9000 9001 11434; do
|
||||
sudo firewall-cmd --permanent --add-port="${port}/tcp" 2>/dev/null || true
|
||||
done
|
||||
sudo firewall-cmd --reload 2>/dev/null || true
|
||||
echo " ✓ Firewall ports opened"
|
||||
elif command -v ufw &>/dev/null && sudo ufw status 2>/dev/null | grep -q "active"; then
|
||||
echo " Configuring ufw..."
|
||||
for port in 3000 8001 8002 8003 8004 9000 9001 11434; do
|
||||
sudo ufw allow "${port}/tcp" 2>/dev/null || true
|
||||
done
|
||||
echo " ✓ UFW ports opened"
|
||||
fi
|
||||
REMOTE_SCRIPT
|
||||
echo ""
|
||||
|
||||
# -------------------------------------------------------
|
||||
# Step 1: Clone or update the repo on the remote host
|
||||
# -------------------------------------------------------
|
||||
echo "--- Step 1: Syncing repository ---"
|
||||
ssh "$REMOTE_HOST" bash -s -- "$REMOTE_DIR" "$REPO_URL" <<'REMOTE_SCRIPT'
|
||||
set -euo pipefail
|
||||
REMOTE_DIR="$1"
|
||||
REPO_URL="$2"
|
||||
|
||||
if [ -d "$REMOTE_DIR/.git" ]; then
|
||||
echo " Updating existing repo..."
|
||||
cd "$REMOTE_DIR"
|
||||
git fetch origin
|
||||
git reset --hard origin/main
|
||||
else
|
||||
echo " Cloning fresh..."
|
||||
git clone "$REPO_URL" "$REMOTE_DIR"
|
||||
cd "$REMOTE_DIR"
|
||||
fi
|
||||
|
||||
echo " ✓ Repo synced at $(git log --oneline -1)"
|
||||
REMOTE_SCRIPT
|
||||
echo ""
|
||||
|
||||
# -------------------------------------------------------
|
||||
# Step 2: Detect or configure Ollama
|
||||
# -------------------------------------------------------
|
||||
echo "--- Step 2: Configuring Ollama ---"
|
||||
# Always use the Docker Ollama container with GPU passthrough
|
||||
# The ollama/ollama image ships with CUDA runtime built-in
|
||||
USE_DOCKER_OLLAMA=true
|
||||
OLLAMA_URL="http://ollama:11434"
|
||||
echo " Using Docker Ollama container (GPU-accelerated via NVIDIA passthrough)"
|
||||
echo " Host-accessible at localhost:11434"
|
||||
echo ""
|
||||
|
||||
# -------------------------------------------------------
|
||||
# Step 3: Create .env and compose override
|
||||
# -------------------------------------------------------
|
||||
echo "--- Step 3: Configuring environment ---"
|
||||
ssh "$REMOTE_HOST" bash -s -- "$REMOTE_DIR" "$OLLAMA_URL" "$OLLAMA_MODEL" "$USE_DOCKER_OLLAMA" <<'REMOTE_SCRIPT'
|
||||
set -euo pipefail
|
||||
REMOTE_DIR="$1"
|
||||
OLLAMA_URL="$2"
|
||||
OLLAMA_MODEL="$3"
|
||||
USE_DOCKER_OLLAMA="$4"
|
||||
cd "$REMOTE_DIR"
|
||||
|
||||
# Read API keys from local files if they exist
|
||||
POLYGON_KEY=""
|
||||
ALPACA_KEY=""
|
||||
ALPACA_SECRET=""
|
||||
ALPACA_URL="https://paper-api.alpaca.markets"
|
||||
|
||||
[ -f polygon.io.key ] && POLYGON_KEY=$(cat polygon.io.key)
|
||||
[ -f alpaca.key ] && ALPACA_KEY=$(cat alpaca.key)
|
||||
[ -f alpaca.secret ] && ALPACA_SECRET=$(cat alpaca.secret)
|
||||
[ -f alpaca.url ] && ALPACA_URL=$(cat alpaca.url)
|
||||
|
||||
cat > .env <<EOF
|
||||
# Stonks Oracle — Docker Deployment Environment
|
||||
MARKET_DATA_API_KEY=${POLYGON_KEY}
|
||||
BROKER_API_KEY=${ALPACA_KEY}
|
||||
BROKER_API_SECRET=${ALPACA_SECRET}
|
||||
BROKER_BASE_URL=${ALPACA_URL}
|
||||
TRADING_ENABLED=true
|
||||
TRADING_RISK_TIER=moderate
|
||||
TRADING_MAX_OPEN_POSITIONS=15
|
||||
OLLAMA_MODEL=${OLLAMA_MODEL}
|
||||
MACRO_ENABLED=true
|
||||
COMPETITIVE_ENABLED=true
|
||||
EOF
|
||||
|
||||
# Create compose override based on Ollama configuration
|
||||
if [ "$USE_DOCKER_OLLAMA" = "true" ]; then
|
||||
# Using Docker Ollama — no override needed, default compose handles it
|
||||
rm -f docker-compose.override.yml
|
||||
echo " ✓ Using Docker Ollama container"
|
||||
else
|
||||
# Using external Ollama — disable the container and point services to it
|
||||
# Determine if URL is localhost (needs host-gateway) or remote
|
||||
if echo "$OLLAMA_URL" | grep -qE "localhost|127\.0\.0\.1"; then
|
||||
DOCKER_OLLAMA_URL="http://host.docker.internal:$(echo "$OLLAMA_URL" | grep -oP ':\K[0-9]+')"
|
||||
cat > docker-compose.override.yml <<EOF
|
||||
services:
|
||||
ollama:
|
||||
entrypoint: ["true"]
|
||||
restart: "no"
|
||||
ports: []
|
||||
extractor:
|
||||
depends_on:
|
||||
postgres:
|
||||
condition: service_healthy
|
||||
redis:
|
||||
condition: service_healthy
|
||||
environment:
|
||||
OLLAMA_BASE_URL: "${DOCKER_OLLAMA_URL}"
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway"
|
||||
recommendation:
|
||||
environment:
|
||||
OLLAMA_BASE_URL: "${DOCKER_OLLAMA_URL}"
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway"
|
||||
EOF
|
||||
else
|
||||
# Remote Ollama — containers can reach it directly
|
||||
cat > docker-compose.override.yml <<EOF
|
||||
services:
|
||||
ollama:
|
||||
entrypoint: ["true"]
|
||||
restart: "no"
|
||||
extractor:
|
||||
depends_on:
|
||||
postgres:
|
||||
condition: service_healthy
|
||||
redis:
|
||||
condition: service_healthy
|
||||
environment:
|
||||
OLLAMA_BASE_URL: "${OLLAMA_URL}"
|
||||
recommendation:
|
||||
environment:
|
||||
OLLAMA_BASE_URL: "${OLLAMA_URL}"
|
||||
EOF
|
||||
fi
|
||||
echo " ✓ Override created — services will use external Ollama at ${OLLAMA_URL}"
|
||||
fi
|
||||
|
||||
echo " ✓ .env configured (polygon=$([ -n "$POLYGON_KEY" ] && echo 'set' || echo 'empty'), alpaca=$([ -n "$ALPACA_KEY" ] && echo 'set' || echo 'empty'))"
|
||||
REMOTE_SCRIPT
|
||||
echo ""
|
||||
|
||||
# -------------------------------------------------------
|
||||
# Step 4: Build and start all services
|
||||
# -------------------------------------------------------
|
||||
echo "--- Step 4: Building and starting services ---"
|
||||
ssh "$REMOTE_HOST" bash -s -- "$REMOTE_DIR" "$USE_DOCKER_OLLAMA" <<'REMOTE_SCRIPT'
|
||||
set -euo pipefail
|
||||
REMOTE_DIR="$1"
|
||||
USE_DOCKER_OLLAMA="$2"
|
||||
cd "$REMOTE_DIR"
|
||||
|
||||
# Stop any existing deployment
|
||||
docker compose down 2>/dev/null || true
|
||||
|
||||
# Build all images
|
||||
echo " Building images (this may take a few minutes)..."
|
||||
docker compose build --quiet 2>&1 | tail -5
|
||||
|
||||
# Start infrastructure
|
||||
echo " Starting infrastructure..."
|
||||
if [ "$USE_DOCKER_OLLAMA" = "true" ]; then
|
||||
docker compose up -d postgres redis minio minio-init ollama
|
||||
else
|
||||
docker compose up -d postgres redis minio minio-init
|
||||
fi
|
||||
|
||||
# Wait for infrastructure to be healthy
|
||||
echo " Waiting for infrastructure health checks..."
|
||||
for svc in postgres redis minio; do
|
||||
for i in $(seq 1 30); do
|
||||
if docker compose ps "$svc" 2>/dev/null | grep -q healthy; then
|
||||
break
|
||||
fi
|
||||
sleep 2
|
||||
done
|
||||
done
|
||||
echo " ✓ Infrastructure healthy"
|
||||
|
||||
# Start all application services
|
||||
echo " Starting application services..."
|
||||
docker compose up -d
|
||||
|
||||
echo " Waiting for services to stabilize..."
|
||||
sleep 20
|
||||
|
||||
# Show status
|
||||
echo ""
|
||||
echo " Service Status:"
|
||||
docker compose ps --format "table {{.Name}}\t{{.Status}}" 2>/dev/null | head -25 || docker compose ps
|
||||
REMOTE_SCRIPT
|
||||
echo ""
|
||||
|
||||
# -------------------------------------------------------
|
||||
# Step 5: Seed the database
|
||||
# -------------------------------------------------------
|
||||
echo "--- Step 5: Seeding database ---"
|
||||
ssh "$REMOTE_HOST" bash -s -- "$REMOTE_DIR" <<'REMOTE_SCRIPT'
|
||||
set -euo pipefail
|
||||
cd "$1"
|
||||
|
||||
# Wait for query-api to be healthy
|
||||
for i in $(seq 1 30); do
|
||||
if docker compose ps query-api 2>/dev/null | grep -q healthy; then
|
||||
break
|
||||
fi
|
||||
sleep 3
|
||||
done
|
||||
|
||||
# Run the symbol registry seed
|
||||
echo " Seeding symbol registry..."
|
||||
docker compose exec -T scheduler python -m services.symbol_registry.seed 2>/dev/null && echo " ✓ Database seeded" || echo " ⚠ Seed skipped (may already be seeded or service not ready)"
|
||||
REMOTE_SCRIPT
|
||||
echo ""
|
||||
|
||||
# -------------------------------------------------------
|
||||
# Step 6: Ensure Ollama model is available
|
||||
# -------------------------------------------------------
|
||||
echo "--- Step 6: Checking Ollama model ---"
|
||||
ssh "$REMOTE_HOST" bash -s -- "$OLLAMA_URL" "$OLLAMA_MODEL" "$USE_DOCKER_OLLAMA" "$REMOTE_DIR" <<'REMOTE_SCRIPT'
|
||||
set -euo pipefail
|
||||
OLLAMA_URL="$1"
|
||||
OLLAMA_MODEL="$2"
|
||||
USE_DOCKER_OLLAMA="$3"
|
||||
REMOTE_DIR="$4"
|
||||
|
||||
if [ "$USE_DOCKER_OLLAMA" = "true" ]; then
|
||||
# Pull via Docker container
|
||||
cd "$REMOTE_DIR"
|
||||
if docker compose exec -T ollama ollama list 2>/dev/null | grep -q "$OLLAMA_MODEL"; then
|
||||
echo " ✓ Model $OLLAMA_MODEL already available"
|
||||
else
|
||||
echo " Pulling $OLLAMA_MODEL via Docker Ollama..."
|
||||
docker compose exec -T ollama ollama pull "$OLLAMA_MODEL"
|
||||
echo " ✓ Model pulled"
|
||||
fi
|
||||
else
|
||||
# Check via API
|
||||
if curl -sf "$OLLAMA_URL/api/tags" 2>/dev/null | grep -q "$OLLAMA_MODEL"; then
|
||||
echo " ✓ Model $OLLAMA_MODEL already available at $OLLAMA_URL"
|
||||
else
|
||||
echo " Pulling $OLLAMA_MODEL via $OLLAMA_URL..."
|
||||
curl -sf "$OLLAMA_URL/api/pull" -d "{\"name\":\"$OLLAMA_MODEL\"}" | tail -1
|
||||
echo " ✓ Model pulled"
|
||||
fi
|
||||
fi
|
||||
REMOTE_SCRIPT
|
||||
echo ""
|
||||
|
||||
# -------------------------------------------------------
|
||||
# Done
|
||||
# -------------------------------------------------------
|
||||
REMOTE_IP=$(echo "$REMOTE_HOST" | cut -d@ -f2)
|
||||
echo "=== Deployment Complete ==="
|
||||
echo ""
|
||||
echo "Endpoints:"
|
||||
echo " Dashboard: http://${REMOTE_IP}:3000"
|
||||
echo " Query API: http://${REMOTE_IP}:8004"
|
||||
echo " Symbol Registry: http://${REMOTE_IP}:8001"
|
||||
echo " Trading Engine: http://${REMOTE_IP}:8002"
|
||||
echo " Risk Engine: http://${REMOTE_IP}:8003"
|
||||
echo " MinIO Console: http://${REMOTE_IP}:9001"
|
||||
echo " Superset: http://${REMOTE_IP}:8088"
|
||||
echo " Ollama: http://${REMOTE_IP}:11434"
|
||||
echo ""
|
||||
echo "Commands:"
|
||||
echo " ssh $REMOTE_HOST 'cd $REMOTE_DIR && docker compose logs -f'"
|
||||
echo " ssh $REMOTE_HOST 'cd $REMOTE_DIR && docker compose ps'"
|
||||
echo " ssh $REMOTE_HOST 'cd $REMOTE_DIR && docker compose down'"
|
||||
@@ -82,6 +82,13 @@ services:
|
||||
- "11434:11434"
|
||||
volumes:
|
||||
- ollama_models:/root/.ollama
|
||||
deploy:
|
||||
resources:
|
||||
reservations:
|
||||
devices:
|
||||
- driver: nvidia
|
||||
count: all
|
||||
capabilities: [gpu]
|
||||
|
||||
trino:
|
||||
image: trinodb/trino:latest
|
||||
@@ -312,6 +319,10 @@ services:
|
||||
<<: *app-env
|
||||
ports:
|
||||
- "8003:8000"
|
||||
networks:
|
||||
default:
|
||||
aliases:
|
||||
- risk
|
||||
depends_on:
|
||||
postgres:
|
||||
condition: service_healthy
|
||||
|
||||
@@ -16,7 +16,9 @@ WORKDIR /app
|
||||
COPY requirements.txt .
|
||||
RUN pip install --no-cache-dir -r requirements.txt
|
||||
|
||||
ARG CACHE_BUST
|
||||
COPY services/ /app/services/
|
||||
COPY scripts/ /app/scripts/
|
||||
COPY tests/ /app/tests/
|
||||
COPY conftest.py /app/conftest.py
|
||||
|
||||
|
||||
+104
-13
@@ -1,6 +1,6 @@
|
||||
# AI Agent Building Guide
|
||||
|
||||
Stonks Oracle uses three AI agents powered by a local Ollama instance. Each agent has a dedicated purpose in the pipeline, a database-backed configuration, and support for A/B testing through variants. This guide covers how each agent works, how to configure them, how to create and test variants, and how to monitor performance.
|
||||
Stonks Oracle uses three AI agents powered by local LLM inference (Ollama or vLLM). Each agent has a dedicated purpose in the pipeline, a database-backed configuration, and support for A/B testing through variants. This guide covers how each agent works, how to configure them, how to create and test variants, and how to monitor performance.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
@@ -8,6 +8,7 @@ Stonks Oracle uses three AI agents powered by a local Ollama instance. Each agen
|
||||
- [Document Intelligence Extractor](#1-document-intelligence-extractor)
|
||||
- [Global Event Classifier](#2-global-event-classifier)
|
||||
- [Thesis Rewriter](#3-thesis-rewriter)
|
||||
- [LLM Provider Abstraction](#llm-provider-abstraction)
|
||||
- [Database Schema](#database-schema)
|
||||
- [ai_agents Table](#ai_agents-table)
|
||||
- [agent_variants Table](#agent_variants-table)
|
||||
@@ -30,9 +31,10 @@ Three agents are seeded into the `ai_agents` table on first migration (migration
|
||||
| **Slug** | `document-extractor` |
|
||||
| **Purpose** | Extracts structured intelligence (sentiment, catalysts, impact scores, key facts, risks) from company news, SEC filings, earnings transcripts, and press releases |
|
||||
| **Default Model** | `qwen3.5:9b-fast` (Ollama) |
|
||||
| **Supported Providers** | `ollama`, `vllm` |
|
||||
| **Prompt Version** | `document-intel-v2` |
|
||||
| **Schema Version** | `2.0.0` |
|
||||
| **Entry Point** | `services/extractor/main.py` → `services/extractor/client.py` |
|
||||
| **Entry Point** | `services/extractor/main.py` → `services/extractor/llm_factory.py` → `services/extractor/client.py` (Ollama) or `services/extractor/vllm_client.py` (vLLM) |
|
||||
|
||||
**Input Data:**
|
||||
- Normalized document text (fetched from MinIO or passed in the Redis job payload)
|
||||
@@ -40,7 +42,7 @@ Three agents are seeded into the `ai_agents` table on first migration (migration
|
||||
- List of tracked tickers for company identification
|
||||
- Document ID for traceability
|
||||
|
||||
**Output Schema** (`ExtractionResult`):
|
||||
**Output Schema** (`ExtractionResult` — defined in `services/extractor/schemas.py`):
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -81,6 +83,7 @@ Use "other" for catalyst_type if unsure. Keep evidence_spans short
|
||||
- Includes tracked ticker list with rules for company identification
|
||||
- Includes the full JSON schema field descriptions
|
||||
- Truncates documents to 8,000 characters to limit inference time
|
||||
- When an active variant has `input_token_limit > 0`, truncation uses `input_token_limit * 4` characters instead
|
||||
|
||||
---
|
||||
|
||||
@@ -91,6 +94,7 @@ Use "other" for catalyst_type if unsure. Keep evidence_spans short
|
||||
| **Slug** | `event-classifier` |
|
||||
| **Purpose** | Classifies global/geopolitical news into structured macro events with impact type, severity, affected regions/sectors/commodities, and estimated duration |
|
||||
| **Default Model** | `qwen3.5:9b-fast` (Ollama) |
|
||||
| **Supported Providers** | `ollama`, `vllm` |
|
||||
| **Prompt Version** | `event-classification-v1` |
|
||||
| **Schema Version** | `1.0.0` |
|
||||
| **Entry Point** | `services/extractor/main.py` → `services/extractor/event_classifier.py` |
|
||||
@@ -99,7 +103,7 @@ Use "other" for catalyst_type if unsure. Keep evidence_spans short
|
||||
- Normalized text of a macro news article (from the `stonks:queue:macro_classification` Redis queue)
|
||||
- Document ID for traceability
|
||||
|
||||
**Output Schema** (`GlobalEvent`):
|
||||
**Output Schema** (`GlobalEvent` — defined in `services/extractor/event_classifier.py`):
|
||||
|
||||
```json
|
||||
{
|
||||
@@ -141,9 +145,11 @@ as empty arrays.
|
||||
```
|
||||
|
||||
**User Prompt Template** (built by `build_event_classification_prompt()` in `services/extractor/event_classifier.py`):
|
||||
- Includes anti-hallucination rules
|
||||
- Includes anti-hallucination rules (no fabrication, severity "critical" reserved for multi-country events)
|
||||
- Lists all valid enum values for each field
|
||||
- Truncates articles to 6,000 characters
|
||||
- When an active variant has `input_token_limit > 0`, truncation uses `input_token_limit * 4` characters instead
|
||||
- If a variant overrides the system prompt, the classifier ensures JSON output instructions are always appended if not already present
|
||||
|
||||
---
|
||||
|
||||
@@ -154,6 +160,7 @@ as empty arrays.
|
||||
| **Slug** | `thesis-rewriter` |
|
||||
| **Purpose** | Rewrites deterministic trade thesis summaries into clear, professional analyst prose. Optional layer — the system falls back to the deterministic thesis if this fails |
|
||||
| **Default Model** | `qwen3.5:9b-fast` (Ollama) |
|
||||
| **Supported Providers** | `ollama`, `vllm` |
|
||||
| **Prompt Version** | `thesis-rewrite-v1` |
|
||||
| **Schema Version** | `1.0.0` |
|
||||
| **Entry Point** | `services/recommendation/main.py` → `services/recommendation/thesis_llm.py` |
|
||||
@@ -165,6 +172,7 @@ as empty arrays.
|
||||
**Output Schema:**
|
||||
- Plain text (not JSON). The model returns only the rewritten thesis as a string, under 150 words.
|
||||
- On failure or empty response, the original deterministic thesis is returned unchanged.
|
||||
- A `_strip_thinking_block()` post-processor removes `<think>` XML tags and "Thinking Process:" blocks that some models (e.g. Qwen3) emit before the actual response.
|
||||
|
||||
**System Prompt:**
|
||||
|
||||
@@ -182,11 +190,37 @@ STRICT RULES:
|
||||
5. Use a neutral, professional tone. Avoid hype or marketing language.
|
||||
6. Return ONLY the rewritten thesis text. No JSON, no markdown, no
|
||||
commentary.
|
||||
7. Do NOT show your thinking process. Do NOT include any reasoning
|
||||
steps. Output ONLY the final rewritten text.
|
||||
```
|
||||
|
||||
**User Prompt Template** (built by `build_thesis_rewrite_prompt()` in `services/recommendation/thesis_llm.py`):
|
||||
- Includes the deterministic thesis between delimiters
|
||||
- Includes trend context: ticker, window, direction, strength, confidence, contradiction score, top catalysts, top risks
|
||||
- Appends `/no_think` suffix to suppress reasoning mode on models that support it (e.g. Qwen3)
|
||||
- Ollama calls also set `"think": false` in the request payload
|
||||
|
||||
---
|
||||
|
||||
## LLM Provider Abstraction
|
||||
|
||||
All three agents support both **Ollama** and **vLLM** as inference providers. The provider is determined by the `model_provider` field in the agent config (or active variant).
|
||||
|
||||
**Module:** `services/extractor/llm_factory.py`
|
||||
|
||||
The `build_llm_client()` factory function routes to the correct client:
|
||||
|
||||
| `model_provider` value | Client class | API endpoint |
|
||||
|------------------------|-------------|--------------|
|
||||
| `ollama` (default), `""`, `None` | `OllamaClient` (`services/extractor/client.py`) | `{OLLAMA_BASE_URL}/api/chat` |
|
||||
| `vllm` | `VLLMClient` (`services/extractor/vllm_client.py`) | `{VLLM_BASE_URL}/v1/chat/completions` (OpenAI-compatible) |
|
||||
| Unknown value | `OllamaClient` (with warning log) | Falls back to Ollama |
|
||||
|
||||
Both clients implement the `LLMClient` protocol (`services/shared/llm_protocol.py`), providing `call_llm()` and `close()` methods.
|
||||
|
||||
**Provider switching at runtime:** When a variant changes the `model_provider`, the extractor worker detects this during its periodic config refresh (every 100 jobs) and creates a new client instance. The old client is closed gracefully. A safety guard prevents switching to Ollama if `OLLAMA_BASE_URL` is empty.
|
||||
|
||||
**vLLM health check:** At startup, if the resolved provider is `vllm`, the extractor runs a health check against the vLLM endpoint. If it fails, the worker falls back to Ollama automatically.
|
||||
|
||||
---
|
||||
|
||||
@@ -202,8 +236,8 @@ Defined in migration `026_ai_agents.sql`. Stores the base configuration for each
|
||||
| `name` | `VARCHAR(100)` | — | Human-readable name (unique) |
|
||||
| `slug` | `VARCHAR(100)` | — | URL-safe identifier (unique), used by `AgentConfigResolver` |
|
||||
| `purpose` | `TEXT` | `''` | Description of what the agent does |
|
||||
| `model_provider` | `VARCHAR(50)` | `'ollama'` | LLM provider |
|
||||
| `model_name` | `VARCHAR(200)` | `'qwen3.5:9b'` | Model identifier |
|
||||
| `model_provider` | `VARCHAR(50)` | `'ollama'` | LLM provider (`ollama` or `vllm`) |
|
||||
| `model_name` | `VARCHAR(200)` | `'qwen3.5:9b-fast'` | Model identifier |
|
||||
| `system_prompt` | `TEXT` | `''` | System prompt sent to the model |
|
||||
| `user_prompt_template` | `TEXT` | `''` | User prompt template (optional — code-defined templates take precedence) |
|
||||
| `prompt_version` | `VARCHAR(100)` | `''` | Version tag for prompt tracking |
|
||||
@@ -297,13 +331,20 @@ The `AgentConfigResolver` is the central mechanism for resolving runtime agent c
|
||||
2. **COALESCE-based override**: The SQL query uses `COALESCE(variant_column, agent_column)` for every configuration field. If an active variant exists and has a non-NULL value for a field, that value is used. Otherwise, the base agent's value is used.
|
||||
|
||||
```sql
|
||||
SELECT a.id AS agent_id,
|
||||
v.id AS variant_id,
|
||||
SELECT a.id AS agent_id,
|
||||
v.id AS variant_id,
|
||||
COALESCE(v.model_provider, a.model_provider) AS model_provider,
|
||||
COALESCE(v.model_name, a.model_name) AS model_name,
|
||||
COALESCE(v.system_prompt, a.system_prompt) AS system_prompt,
|
||||
COALESCE(v.user_prompt_template, a.user_prompt_template) AS user_prompt_template,
|
||||
-- ... all other fields ...
|
||||
COALESCE(v.prompt_version, a.prompt_version) AS prompt_version,
|
||||
COALESCE(v.temperature, a.temperature) AS temperature,
|
||||
COALESCE(v.max_tokens, a.max_tokens) AS max_tokens,
|
||||
COALESCE(v.context_window, 0) AS context_window,
|
||||
COALESCE(v.input_token_limit, 0) AS input_token_limit,
|
||||
COALESCE(v.token_budget, 0) AS token_budget,
|
||||
COALESCE(v.timeout_seconds, a.timeout_seconds) AS timeout_seconds,
|
||||
COALESCE(v.max_retries, a.max_retries) AS max_retries
|
||||
FROM ai_agents a
|
||||
LEFT JOIN agent_variants v
|
||||
ON v.agent_id = a.id AND v.is_active = TRUE
|
||||
@@ -361,7 +402,10 @@ resolver.invalidate() # Clear all entries
|
||||
|
||||
### Config Refresh in Workers
|
||||
|
||||
The extractor and recommendation workers periodically re-resolve their agent config (every 100 jobs for the extractor, every 50 jobs for the recommendation worker). If the resolved model changes, the worker creates a new `OllamaClient` instance with the updated configuration.
|
||||
The extractor and recommendation workers periodically re-resolve their agent config to pick up variant swaps and model changes:
|
||||
|
||||
- **Extractor worker** (`services/extractor/main.py`): Re-resolves both `document-extractor` and `event-classifier` configs every **100 jobs**. If the resolved model or provider changes, the worker creates a new LLM client instance via `build_llm_client()` and closes the old one. A safety guard prevents switching to Ollama if `OLLAMA_BASE_URL` is empty.
|
||||
- **Recommendation worker** (`services/recommendation/main.py`): Re-resolves the `thesis-rewriter` config every **50 jobs**. If the model changes, a new `OllamaConfig` is built.
|
||||
|
||||
---
|
||||
|
||||
@@ -373,7 +417,7 @@ Every agent invocation is logged to `agent_performance_log` with the `agent_id`
|
||||
|
||||
- **Document extractor**: Logged in `services/extractor/main.py` after each extraction. Records success/failure, duration, confidence, retry count, token estimates.
|
||||
- **Event classifier**: Logged in `services/extractor/event_classifier.py` after each classification. Same fields.
|
||||
- **Thesis rewriter**: Logged in `services/recommendation/thesis_llm.py` after each rewrite attempt. Confidence is always 0.0 (not applicable for rewrites).
|
||||
- **Thesis rewriter**: Logged in `services/recommendation/thesis_llm.py` after each rewrite attempt. Confidence is always 0.0 (not applicable for rewrites). `document_id` is always NULL.
|
||||
|
||||
### Querying for Variant Comparison
|
||||
|
||||
@@ -464,6 +508,8 @@ All agent endpoints are served by the Query API (`services/api/app.py`) under th
|
||||
}
|
||||
```
|
||||
|
||||
All fields except `name` have defaults. The `slug` is auto-generated from `name` if not provided. The `model_name` defaults to `llama3.1:8b` for user-created agents.
|
||||
|
||||
**Update Agent Request Body** (all fields optional):
|
||||
|
||||
```json
|
||||
@@ -509,6 +555,30 @@ All agent endpoints are served by the Query API (`services/api/app.py`) under th
|
||||
| `PUT` | `/api/agents/{agent_id}/variants/{variant_id}` | Partial update a variant |
|
||||
| `DELETE` | `/api/agents/{agent_id}/variants/{variant_id}` | Delete a variant (returns 400 if active) |
|
||||
|
||||
**Create Variant Request Body:**
|
||||
|
||||
```json
|
||||
{
|
||||
"variant_name": "Llama 3.1 8B Test",
|
||||
"variant_slug": "llama-3-1-8b-test",
|
||||
"description": "Testing llama3.1:8b as an alternative",
|
||||
"model_provider": "ollama",
|
||||
"model_name": "llama3.1:8b",
|
||||
"system_prompt": "",
|
||||
"user_prompt_template": "",
|
||||
"prompt_version": "",
|
||||
"temperature": 0.0,
|
||||
"max_tokens": 32768,
|
||||
"context_window": 0,
|
||||
"input_token_limit": 0,
|
||||
"token_budget": 0,
|
||||
"timeout_seconds": 120,
|
||||
"max_retries": 2
|
||||
}
|
||||
```
|
||||
|
||||
Required fields: `variant_name`, `model_name`. The `variant_slug` is auto-generated from `variant_name` if not provided.
|
||||
|
||||
### Clone Endpoints
|
||||
|
||||
| Method | Path | Description |
|
||||
@@ -516,7 +586,7 @@ All agent endpoints are served by the Query API (`services/api/app.py`) under th
|
||||
| `POST` | `/api/agents/{agent_id}/clone` | Clone an agent's base config as a new variant |
|
||||
| `POST` | `/api/agents/{agent_id}/variants/{variant_id}/clone` | Clone an existing variant as a new variant |
|
||||
|
||||
Clone requests copy all configuration fields from the source, with optional overrides in the request body.
|
||||
Clone requests copy all configuration fields from the source, with optional overrides in the request body. The `variant_name` field is required. All other fields default to the source's values if not provided.
|
||||
|
||||
### Activate / Deactivate
|
||||
|
||||
@@ -525,6 +595,8 @@ Clone requests copy all configuration fields from the source, with optional over
|
||||
| `POST` | `/api/agents/{agent_id}/variants/{variant_id}/activate` | Set a variant as active (deactivates any other active variant in a single transaction) |
|
||||
| `POST` | `/api/agents/{agent_id}/variants/deactivate` | Deactivate the currently active variant (agent falls back to base config) |
|
||||
|
||||
The activate endpoint uses a database transaction to atomically deactivate the current variant and activate the new one, ensuring exactly one active variant at all times.
|
||||
|
||||
### Per-Variant Performance
|
||||
|
||||
| Method | Path | Description |
|
||||
@@ -532,6 +604,8 @@ Clone requests copy all configuration fields from the source, with optional over
|
||||
| `GET` | `/api/agents/{agent_id}/variants/{variant_id}/performance` | Aggregated metrics for a specific variant |
|
||||
| `GET` | `/api/agents/{agent_id}/variants/{variant_id}/performance/history` | Hourly time-series for a specific variant |
|
||||
|
||||
Both endpoints accept the same `hours` query parameter (default 24, max 720) and return the same response shape as the agent-level performance endpoints.
|
||||
|
||||
---
|
||||
|
||||
## Step-by-Step: Creating and Activating a Variant
|
||||
@@ -616,3 +690,20 @@ curl -s -X PUT \
|
||||
```
|
||||
|
||||
Then re-activate and compare again.
|
||||
|
||||
### 7. Switch to vLLM Provider
|
||||
|
||||
To test a variant using vLLM instead of Ollama:
|
||||
|
||||
```bash
|
||||
curl -s -X POST https://stonks-api.celestium.life/api/agents/$AGENT_ID/clone \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"variant_name": "vLLM Qwen3 Test",
|
||||
"description": "Testing extraction with vLLM backend",
|
||||
"model_provider": "vllm",
|
||||
"model_name": "Qwen/Qwen3-8B"
|
||||
}' | jq .
|
||||
```
|
||||
|
||||
The extractor worker will detect the provider change during its next config refresh and build a `VLLMClient` instead of an `OllamaClient`. Ensure the `VLLM_BASE_URL` environment variable is set in the extractor deployment.
|
||||
+185
-19
@@ -142,14 +142,35 @@ Trend projection for a specific trend window.
|
||||
### 1.5 Market Prices
|
||||
|
||||
#### `GET /api/market/prices/{ticker}`
|
||||
Historical close prices from `market_snapshots`.
|
||||
Historical OHLCV bars from `market_snapshots`, deduplicated by bar timestamp and ordered oldest-first. Also returns 90-day high/low range.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `limit` | int | `30` | max `200` | Max bars returned |
|
||||
| `limit` | int | `200` | max `500` | Max bars returned |
|
||||
|
||||
- **Path params:** `ticker` (auto-uppercased)
|
||||
- **Response:** Array of OHLCV objects ordered oldest-first
|
||||
- **Response:** `{ bars: [{ ticker, close, open, high, low, volume, bar_timestamp, captured_at }], range_90d: { low, high } }`
|
||||
|
||||
#### `POST /api/market/backfill/{ticker}`
|
||||
Backfill daily OHLCV bars from Polygon for the last N days. Deduplicates by bar timestamp.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `days` | int | `90` | max `365` | Number of days to backfill |
|
||||
|
||||
- **Path params:** `ticker` (auto-uppercased)
|
||||
- **Response:** `{ ticker, inserted, total_bars, days }`
|
||||
- **Errors:** `503` — No market data API key configured
|
||||
|
||||
#### `POST /api/market/backfill-all`
|
||||
Backfill daily bars for all active companies from Polygon.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `days` | int | `90` | max `365` | Number of days to backfill |
|
||||
|
||||
- **Response:** `{ total_inserted, tickers, details[] }` — each detail has `{ ticker, inserted }` or `{ ticker, inserted: 0, error }`
|
||||
- **Errors:** `503` — No market data API key configured
|
||||
|
||||
### 1.6 Recommendations
|
||||
|
||||
@@ -224,8 +245,6 @@ Get audit events for any entity type and ID.
|
||||
|
||||
- **Path params:** `entity_type` (string), `entity_id` (string)
|
||||
- **Response:** Array of audit event objects
|
||||
- **Errors:** `404` — No audit events found
|
||||
|
||||
|
||||
### 1.10 Admin: Source Health
|
||||
|
||||
@@ -331,6 +350,8 @@ Approve or reject a pending operator approval request.
|
||||
#### `GET /api/admin/trading/lockouts`
|
||||
List active symbol lockouts (news-shock, cooldown, manual).
|
||||
|
||||
- **Response:** Array of lockout objects
|
||||
|
||||
#### `POST /api/admin/trading/lockouts`
|
||||
Create a manual symbol lockout.
|
||||
|
||||
@@ -353,7 +374,6 @@ Update operator approval settings.
|
||||
- **Body:** `{ auto_approve_paper?: bool, require_approval_for_live?: bool, approval_timeout_minutes?: int }`
|
||||
- **Response:** Updated approval settings
|
||||
|
||||
|
||||
### 1.13 Operational Dashboard
|
||||
|
||||
#### `GET /api/ops/ingestion/throughput`
|
||||
@@ -450,7 +470,7 @@ Trino catalog/schema/table/column metadata for the schema browser.
|
||||
#### `GET /api/analytics/pg-schema`
|
||||
PostgreSQL table/column metadata with primary keys, foreign keys, and row estimates.
|
||||
|
||||
- **Response:** `{ catalog: "postgresql", schema: "public", tables[] }`
|
||||
- **Response:** `{ catalog: "postgresql", schema: "public", tables[{ name, row_estimate, columns[{ name, type, nullable, primary_key?, references?, has_default? }] }] }`
|
||||
|
||||
#### `POST /api/analytics/pg-query`
|
||||
Run read-only SQL against PostgreSQL directly. Only SELECT statements allowed.
|
||||
@@ -462,17 +482,19 @@ Run read-only SQL against PostgreSQL directly. Only SELECT statements allowed.
|
||||
#### `GET /api/analytics/saved-queries`
|
||||
List all saved queries.
|
||||
|
||||
- **Response:** Array of `{ id, name, description, sql_text, created_by, created_at, updated_at }`
|
||||
|
||||
#### `POST /api/analytics/saved-queries` (201)
|
||||
Save a new query.
|
||||
|
||||
- **Body:** `{ name: string, description?: string, sql_text: string }`
|
||||
- **Response:** `{ id, name, description, sql_text, created_by, created_at }`
|
||||
|
||||
#### `DELETE /api/analytics/saved-queries/{query_id}`
|
||||
Delete a saved query.
|
||||
|
||||
- **Errors:** `404` — Query not found
|
||||
|
||||
|
||||
### 1.16 Macro Signal Layer
|
||||
|
||||
#### `GET /api/admin/macro/status`
|
||||
@@ -501,9 +523,13 @@ List recent global events with filtering.
|
||||
| `limit` | int | `50` | max `200` | Page size |
|
||||
| `offset` | int | `0` | — | Pagination offset |
|
||||
|
||||
- **Response:** Array of global event objects with `id`, `event_types`, `severity`, `affected_regions`, `affected_sectors`, `affected_commodities`, `summary`, `key_facts`, `estimated_duration`, `confidence`, `source_document_id`, `created_at`
|
||||
|
||||
#### `GET /api/macro/events/{event_id}`
|
||||
Event detail with affected companies and macro impact scores.
|
||||
|
||||
- **Path params:** `event_id` (UUID string)
|
||||
- **Response:** Global event object + `impacts[]` (each with `company_id`, `ticker`, `macro_impact_score`, `impact_direction`, `contributing_factors`, `confidence`, `legal_name`, `sector`)
|
||||
- **Errors:** `404` — Global event not found
|
||||
|
||||
#### `GET /api/macro/impacts/{ticker}`
|
||||
@@ -515,7 +541,8 @@ Macro impacts and exposure profile for a specific company.
|
||||
| `limit` | int | `50` | max `200` | Page size |
|
||||
| `offset` | int | `0` | — | Pagination offset |
|
||||
|
||||
- **Response:** `{ exposure_profile, impacts[] }`
|
||||
- **Path params:** `ticker` (auto-uppercased)
|
||||
- **Response:** `{ exposure_profile, impacts[] }` — each impact includes `event_summary`, `event_severity`, `event_types`, `affected_regions`
|
||||
|
||||
### 1.18 Competitive Signal Layer
|
||||
|
||||
@@ -540,6 +567,7 @@ Historical patterns for a company.
|
||||
| `catalyst_type` | string | — | Filter by catalyst type |
|
||||
| `time_horizon` | string | — | Filter by time horizon |
|
||||
|
||||
- **Path params:** `ticker` (string)
|
||||
- **Response:** `{ ticker, patterns[], count }`
|
||||
|
||||
#### `GET /api/patterns/{ticker}/competitors`
|
||||
@@ -555,6 +583,7 @@ Cross-company patterns showing how this company's catalysts affected competitors
|
||||
#### `GET /api/patterns/{ticker}/competitive-signals`
|
||||
Recent competitive signals targeting this company (limit 100).
|
||||
|
||||
- **Path params:** `ticker` (string)
|
||||
- **Response:** `{ ticker, competitive_signals[], count }`
|
||||
|
||||
#### `GET /api/patterns/{ticker}/decisions`
|
||||
@@ -564,9 +593,9 @@ Major corporate decision history with trend outcomes and pattern statistics.
|
||||
|-----------|------|---------|-------------|
|
||||
| `time_horizon` | string | — | Filter by time horizon |
|
||||
|
||||
- **Path params:** `ticker` (string)
|
||||
- **Response:** `{ ticker, decisions[], count }` — each decision includes `pattern_statistics[]`
|
||||
|
||||
|
||||
### 1.20 AI Agents
|
||||
|
||||
#### `GET /api/agents`
|
||||
@@ -576,9 +605,12 @@ List all AI agent configurations.
|
||||
|-----------|------|---------|-------------|
|
||||
| `active_only` | bool | `false` | Only show active agents |
|
||||
|
||||
- **Response:** Array of agent objects with `id`, `name`, `slug`, `purpose`, `model_provider`, `model_name`, `system_prompt`, `user_prompt_template`, `prompt_version`, `schema_version`, `temperature`, `max_tokens`, `timeout_seconds`, `max_retries`, `active`, `source`, `created_at`, `updated_at`
|
||||
|
||||
#### `GET /api/agents/{agent_id}`
|
||||
Get a single agent configuration.
|
||||
|
||||
- **Path params:** `agent_id` (UUID string)
|
||||
- **Errors:** `404` — Agent not found
|
||||
|
||||
#### `POST /api/agents` (201)
|
||||
@@ -603,9 +635,9 @@ Create a new user-defined agent.
|
||||
| `max_retries` | int | `2` | Max retry attempts |
|
||||
|
||||
#### `PUT /api/agents/{agent_id}`
|
||||
Update an agent configuration. Partial updates supported.
|
||||
Update an agent configuration. Partial updates supported — only provided fields are changed.
|
||||
|
||||
- **Body:** `AgentUpdateBody` — all fields optional (same fields as create)
|
||||
- **Body:** `AgentUpdateBody` — all fields optional (same fields as create plus `active`)
|
||||
- **Errors:** `400` — No fields to update; `404` — Agent not found
|
||||
|
||||
#### `DELETE /api/agents/{agent_id}`
|
||||
@@ -636,6 +668,8 @@ Hourly performance time-series for an agent.
|
||||
#### `GET /api/agents/{agent_id}/variants`
|
||||
List all variants for an agent, ordered by `created_at` ascending.
|
||||
|
||||
- **Response:** Array of variant objects with `id`, `agent_id`, `variant_name`, `variant_slug`, `description`, `model_provider`, `model_name`, `system_prompt`, `user_prompt_template`, `prompt_version`, `temperature`, `max_tokens`, `context_window`, `input_token_limit`, `token_budget`, `timeout_seconds`, `max_retries`, `is_active`, `created_at`, `updated_at`
|
||||
|
||||
#### `GET /api/agents/{agent_id}/variants/{variant_id}`
|
||||
Get a single variant.
|
||||
|
||||
@@ -680,13 +714,13 @@ Delete a variant. Cannot delete active variants.
|
||||
#### `POST /api/agents/{agent_id}/clone` (201)
|
||||
Clone an agent's configuration as a new variant with optional overrides.
|
||||
|
||||
- **Body:** `VariantCloneBody { variant_name, variant_slug?, ...optional overrides }`
|
||||
- **Body:** `VariantCloneBody { variant_name, variant_slug?, description?, model_provider?, model_name?, system_prompt?, user_prompt_template?, prompt_version?, temperature?, max_tokens?, context_window?, input_token_limit?, token_budget?, timeout_seconds?, max_retries? }`
|
||||
- **Errors:** `404` — Agent not found; `409` — Duplicate slug
|
||||
|
||||
#### `POST /api/agents/{agent_id}/variants/{variant_id}/clone` (201)
|
||||
Clone an existing variant as a new variant with optional overrides.
|
||||
|
||||
- **Body:** `VariantCloneBody`
|
||||
- **Body:** `VariantCloneBody` (same as above)
|
||||
- **Errors:** `404` — Source variant not found; `409` — Duplicate slug
|
||||
|
||||
#### `POST /api/agents/{agent_id}/variants/{variant_id}/activate`
|
||||
@@ -697,6 +731,8 @@ Set a variant as the active variant for its agent. Deactivates any currently act
|
||||
#### `POST /api/agents/{agent_id}/variants/deactivate`
|
||||
Deactivate the currently active variant. Agent falls back to base configuration.
|
||||
|
||||
- **Response:** `{ deactivated: true }`
|
||||
|
||||
#### `GET /api/agents/{agent_id}/variants/{variant_id}/performance`
|
||||
Aggregated performance metrics for a specific variant.
|
||||
|
||||
@@ -704,6 +740,8 @@ Aggregated performance metrics for a specific variant.
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `hours` | int | `24` | max `720` | Time window |
|
||||
|
||||
- **Response:** Same shape as agent performance (invocations, successes, failures, durations, confidence, tokens, success_rate)
|
||||
|
||||
#### `GET /api/agents/{agent_id}/variants/{variant_id}/performance/history`
|
||||
Hourly performance time-series for a specific variant.
|
||||
|
||||
@@ -711,6 +749,108 @@ Hourly performance time-series for a specific variant.
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `hours` | int | `24` | max `720` | Time window |
|
||||
|
||||
- **Response:** Array of `{ hour, invocations, successes, avg_duration_ms, avg_confidence }`
|
||||
|
||||
### 1.22 Model Validation
|
||||
|
||||
#### `GET /api/validation/summary`
|
||||
Latest model metric snapshot plus quality gate status.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `lookback` | string | `"30d"` | `7d`, `30d`, `90d`, `all` | Lookback window |
|
||||
| `horizon` | string | `"7d"` | `1h`, `6h`, `1d`, `7d`, `30d` | Prediction horizon |
|
||||
|
||||
- **Response:** `{ snapshot: { id, generated_at, lookback_window, horizon, prediction_count, win_rate, directional_accuracy, information_coefficient, rank_information_coefficient, avg_return, avg_excess_return_vs_spy, avg_excess_return_vs_sector, calibration_error, brier_score, buy_win_rate, sell_win_rate, hold_win_rate, metadata }, gate_status }`
|
||||
- **Errors:** `400` — Invalid lookback or horizon value
|
||||
|
||||
#### `GET /api/validation/calibration`
|
||||
Calibration table with confidence buckets showing predicted vs observed win rates.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `lookback` | string | `"30d"` | `7d`, `30d`, `90d`, `all` | Lookback window |
|
||||
| `horizon` | string | `"7d"` | `1h`, `6h`, `1d`, `7d`, `30d` | Prediction horizon |
|
||||
|
||||
- **Response:** `{ buckets: [{ bucket_low, bucket_high, avg_confidence, observed_win_rate, prediction_count, miscalibrated }], lookback, horizon }`
|
||||
- Buckets: 0.50–0.60, 0.60–0.70, 0.70–0.80, 0.80–0.90, 0.90–1.00
|
||||
- `miscalibrated` is `true` when `|avg_confidence - observed_win_rate| > 0.15`
|
||||
- **Errors:** `400` — Invalid lookback or horizon value
|
||||
|
||||
#### `GET /api/validation/ic-by-horizon`
|
||||
Information Coefficient and Rank IC per prediction horizon.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `lookback` | string | `"30d"` | `7d`, `30d`, `90d`, `all` | Lookback window |
|
||||
|
||||
- **Response:** `{ horizons: [{ horizon, information_coefficient, rank_information_coefficient, prediction_count, generated_at }], lookback }`
|
||||
- Horizons ordered: `1h`, `6h`, `1d`, `7d`, `30d`
|
||||
- **Errors:** `400` — Invalid lookback value
|
||||
|
||||
#### `GET /api/validation/gate-status`
|
||||
Quality gate evaluation detail from `risk_configs` where `name = 'model_quality_gate'`.
|
||||
|
||||
- **Response:** `{ gate_status, updated_at }` or `{ gate_status: null, message: "No gate evaluation found..." }`
|
||||
|
||||
### 1.23 Attribution
|
||||
|
||||
#### `GET /api/validation/attribution/sources`
|
||||
Per-source performance metrics: win rate, IC, average return, duplicate rate.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `lookback` | string | `"30d"` | `7d`, `30d`, `90d`, `all` | Lookback window |
|
||||
| `horizon` | string | `"7d"` | `1h`, `6h`, `1d`, `7d`, `30d` | Prediction horizon |
|
||||
|
||||
- **Response:** `{ sources[], lookback, horizon }`
|
||||
- **Errors:** `400` — Invalid lookback or horizon; `500` — Computation failed
|
||||
|
||||
#### `GET /api/validation/attribution/catalysts`
|
||||
Per-catalyst-type performance metrics: win rate, IC, average return.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `lookback` | string | `"30d"` | `7d`, `30d`, `90d`, `all` | Lookback window |
|
||||
| `horizon` | string | `"7d"` | `1h`, `6h`, `1d`, `7d`, `30d` | Prediction horizon |
|
||||
|
||||
- **Response:** `{ catalysts[], lookback, horizon }`
|
||||
- **Errors:** `400` — Invalid lookback or horizon; `500` — Computation failed
|
||||
|
||||
#### `GET /api/validation/attribution/layers`
|
||||
Per-signal-layer (company, macro, competitive) performance metrics.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `lookback` | string | `"30d"` | `7d`, `30d`, `90d`, `all` | Lookback window |
|
||||
| `horizon` | string | `"7d"` | `1h`, `6h`, `1d`, `7d`, `30d` | Prediction horizon |
|
||||
|
||||
- **Response:** `{ layers[], lookback, horizon }` — each layer has `avg_contribution_pct`, `dominant_win_rate`, `dominant_ic`
|
||||
- **Errors:** `400` — Invalid lookback or horizon; `500` — Computation failed
|
||||
|
||||
### 1.24 Trading Reports
|
||||
|
||||
#### `GET /api/reports`
|
||||
Paginated list of trading reports with optional filtering.
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `report_type` | string | — | `daily` or `weekly` | Filter by report type |
|
||||
| `start_date` | string | — | ISO date (YYYY-MM-DD) | Filter `period_start >= this` |
|
||||
| `end_date` | string | — | ISO date (YYYY-MM-DD) | Filter `period_end <= this` |
|
||||
| `limit` | int | `20` | max `100` | Page size |
|
||||
| `offset` | int | `0` | min `0` | Pagination offset |
|
||||
|
||||
- **Response:** Array of `{ id, report_type, period_start, period_end, validation_status, generated_at }`
|
||||
- **Errors:** `400` — Invalid `report_type` or date format
|
||||
|
||||
#### `GET /api/reports/{report_id}`
|
||||
Fetch a single report including full `report_data` JSONB.
|
||||
|
||||
- **Path params:** `report_id` (UUID string)
|
||||
- **Response:** `{ id, report_type, period_start, period_end, report_data, validation_status, generated_at, created_at }`
|
||||
- **Errors:** `404` — Report not found
|
||||
|
||||
---
|
||||
|
||||
## 2. Symbol Registry API
|
||||
@@ -756,6 +896,7 @@ List tracked companies.
|
||||
#### `GET /companies/{company_id}`
|
||||
Get a single company.
|
||||
|
||||
- **Path params:** `company_id` (UUID string)
|
||||
- **Errors:** `404` — Company not found
|
||||
|
||||
#### `PUT /companies/{company_id}`
|
||||
@@ -783,14 +924,18 @@ List aliases for a company.
|
||||
Create a new watchlist.
|
||||
|
||||
- **Body:** `{ name: string, description?: string }`
|
||||
- **Response:** `{ id, name, description, active }`
|
||||
- **Errors:** `409` — Watchlist name already exists
|
||||
|
||||
#### `GET /watchlists`
|
||||
List all watchlists.
|
||||
|
||||
- **Response:** Array of `{ id, name, description, active }`
|
||||
|
||||
#### `POST /watchlists/{watchlist_id}/members/{company_id}` (201)
|
||||
Add a company to a watchlist.
|
||||
|
||||
- **Response:** `{ status: "added" }`
|
||||
- **Errors:** `409` — Already a member; `404` — Watchlist or company not found
|
||||
|
||||
#### `GET /watchlists/{watchlist_id}/members`
|
||||
@@ -814,11 +959,14 @@ Add a data source for a company.
|
||||
| `retention_days` | int | `365` | — | Data retention period |
|
||||
| `access_policy` | string | `"internal"` | `internal`, `public`, `restricted` | Access policy |
|
||||
|
||||
- **Response:** `{ id, source_type, source_name, credibility_score, active }`
|
||||
- **Errors:** `404` — Company not found; `422` — Invalid source_type or access_policy
|
||||
|
||||
#### `GET /companies/{company_id}/sources`
|
||||
List sources for a company.
|
||||
|
||||
- **Response:** Array of `{ id, source_type, source_name, config, credibility_score, retention_days, access_policy, active }`
|
||||
|
||||
### 2.6 Exposure Profiles
|
||||
|
||||
#### `GET /companies/{company_id}/exposure`
|
||||
@@ -848,6 +996,8 @@ Create or update an exposure profile. Archives the previous active version.
|
||||
#### `GET /companies/{company_id}/exposure/history`
|
||||
Get all exposure profile versions for a company, ordered by version descending.
|
||||
|
||||
- **Response:** Array of `ExposureProfileResponse`
|
||||
|
||||
### 2.7 Competitor Relationships
|
||||
|
||||
#### `POST /companies/{company_id}/competitors` (201)
|
||||
@@ -863,10 +1013,11 @@ Create a competitor relationship. Records an audit event.
|
||||
| `bidirectional` | bool | `true` | — | Bidirectional relationship |
|
||||
| `source` | string | `"manual"` | `manual`, `inferred` | Data source |
|
||||
|
||||
- **Response:** `CompetitorRelationship { id, company_a_id, company_b_id, relationship_type, strength, bidirectional, source, active, created_at, updated_at }`
|
||||
- **Errors:** `400` — Self-reference; `404` — Company not found; `409` — Relationship already exists
|
||||
|
||||
#### `GET /companies/{company_id}/competitors`
|
||||
List active competitor relationships, enriched with ticker and legal_name of the other company.
|
||||
List active competitor relationships, enriched with `ticker` and `legal_name` of the other company. Ordered by strength descending.
|
||||
|
||||
- **Errors:** `404` — Company not found
|
||||
|
||||
@@ -879,6 +1030,7 @@ Update a competitor relationship. Records an audit event with previous state.
|
||||
#### `DELETE /companies/{company_id}/competitors/{relationship_id}`
|
||||
Soft-delete a competitor relationship (sets `active=false`). Records an audit event.
|
||||
|
||||
- **Response:** `{ status: "deleted", id }`
|
||||
- **Errors:** `404` — Active relationship not found
|
||||
|
||||
### 2.8 Competitor Inference
|
||||
@@ -923,7 +1075,7 @@ Diagnostic endpoint showing engine internals for troubleshooting.
|
||||
#### `GET /api/trading/status`
|
||||
Return current engine state.
|
||||
|
||||
- **Response:** `{ enabled, paused, risk_tier, circuit_breaker_status, active_pool, reserve_pool, portfolio_heat, open_positions, last_decision_at }`
|
||||
- **Response:** `{ enabled, paused, risk_tier, circuit_breaker_status, active_pool, reserve_pool, portfolio_heat, open_positions, open_position_count, max_open_positions, absolute_position_cap, last_decision_at }`
|
||||
- **Errors:** `503` — Engine not initialised
|
||||
|
||||
#### `PUT /api/trading/config`
|
||||
@@ -960,7 +1112,13 @@ Resume the trading engine.
|
||||
#### `POST /api/trading/reset`
|
||||
Full paper trading reset: liquidate broker positions, cancel orders, clear trading state, reset capital.
|
||||
|
||||
- **Body:** `{ initial_capital?: float (default 0.0) }` — if 0, uses broker balance or defaults to 100,000
|
||||
- **Body:** `CapitalRequest`
|
||||
|
||||
| Field | Type | Default | Description |
|
||||
|-------|------|---------|-------------|
|
||||
| `initial_capital` | float | `0.0` | If 0, uses broker balance or defaults to 100,000 |
|
||||
| `reserve_pct` | float | `null` | Reserve pool percentage (0–1). If null, uses engine config `reserve_siphon_pct` |
|
||||
|
||||
- **Response:** `{ reset: true, initial_capital, active_pool, reserve_pool, broker: { orders_cancelled, positions_closed, portfolio_value, cash, buying_power } }`
|
||||
- **Errors:** `503` — Engine not initialised; `500` — Database reset failed
|
||||
|
||||
@@ -977,6 +1135,8 @@ Return recent trading decisions from the database.
|
||||
| `limit` | int | `50` | max `200` | Page size |
|
||||
| `offset` | int | `0` | — | Pagination offset |
|
||||
|
||||
- **Response:** Array of `{ id, recommendation_id, decision, skip_reason, ticker, computed_position_size, computed_share_quantity, risk_tier_at_decision, portfolio_heat_at_decision, active_pool_at_decision, reserve_pool_at_decision, circuit_breaker_status, is_micro_trade, created_at }`
|
||||
|
||||
### 3.5 Performance Metrics
|
||||
|
||||
#### `GET /api/trading/metrics`
|
||||
@@ -992,6 +1152,8 @@ Return historical daily portfolio snapshots.
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
| `limit` | int | `30` | max `365` | Max snapshots |
|
||||
|
||||
- **Response:** Array of `{ id, snapshot_date, portfolio_value, active_pool, reserve_pool, daily_return, cumulative_return, unrealized_pnl, realized_pnl, win_count, loss_count, win_rate, sharpe_ratio, max_drawdown, current_drawdown_pct, portfolio_heat, risk_tier, created_at }`
|
||||
|
||||
### 3.6 Backtesting
|
||||
|
||||
#### `POST /api/trading/backtest`
|
||||
@@ -1012,6 +1174,7 @@ Launch a backtest run asynchronously.
|
||||
#### `GET /api/trading/backtest/{backtest_id}`
|
||||
Retrieve backtest results.
|
||||
|
||||
- **Path params:** `backtest_id` (UUID string)
|
||||
- **Response:** `{ id, start_date, end_date, initial_capital, risk_tier, config, total_return, sharpe_ratio, max_drawdown, win_rate, profit_factor, trade_count, equity_curve[], trades[], status, completed_at, created_at }`
|
||||
- Status values: `running`, `completed`, `not_found`, `pending`
|
||||
|
||||
@@ -1037,10 +1200,11 @@ Update notification preferences.
|
||||
|
||||
All fields optional.
|
||||
|
||||
- **Response:** `{ updated: { ...changed fields } }`
|
||||
- **Errors:** `503` — Engine not initialised
|
||||
|
||||
#### `GET /api/trading/notifications/history`
|
||||
Return recent notifications.
|
||||
Return recent notifications (placeholder — currently returns empty array).
|
||||
|
||||
| Parameter | Type | Default | Constraints | Description |
|
||||
|-----------|------|---------|-------------|-------------|
|
||||
@@ -1116,6 +1280,8 @@ List pending approval requests.
|
||||
#### `GET /approvals/{approval_id}`
|
||||
Get a single approval request.
|
||||
|
||||
- **Path params:** `approval_id` (UUID string)
|
||||
- **Response:** Approval request object
|
||||
- **Errors:** `404` — Approval not found; `503` — Database not ready
|
||||
|
||||
#### `POST /approvals/{approval_id}/review`
|
||||
@@ -1138,4 +1304,4 @@ Approve or reject a pending approval request.
|
||||
Expire stale approvals that have passed their expiration time.
|
||||
|
||||
- **Response:** `{ expired: int, items: [] }`
|
||||
- **Errors:** `503` — Database not ready
|
||||
- **Errors:** `503` — Database not ready
|
||||
|
||||
@@ -18,13 +18,13 @@ flowchart TB
|
||||
end
|
||||
|
||||
%% ── Scheduler ─────────────────────────────────────────────────
|
||||
scheduler["<b>Scheduler</b><br/><i>services.scheduler.app</i><br/>Cadence polling, rate limiting,<br/>backoff & stale recovery"]
|
||||
scheduler["<b>Scheduler</b><br/><i>services.scheduler.app</i><br/>Cadence polling, rate limiting,<br/>backoff, stale recovery,<br/>periodic aggregation,<br/>report scheduling"]
|
||||
|
||||
sources -.->|"API polling<br/>on cadence"| scheduler
|
||||
|
||||
%% ── Ingestion Queue ───────────────────────────────────────────
|
||||
q_ingestion[["stonks:queue:ingestion"]]
|
||||
scheduler -->|"rpush job"| q_ingestion
|
||||
scheduler -->|"rpush job<br/>(company, macro,<br/>global market)"| q_ingestion
|
||||
|
||||
%% ── Ingestion Worker ──────────────────────────────────────────
|
||||
ingestion["<b>Ingestion</b><br/><i>services.ingestion.worker</i><br/>Adapter dispatch, dedupe,<br/>raw artifact upload"]
|
||||
@@ -42,7 +42,7 @@ flowchart TB
|
||||
|
||||
%% ── Parsing Queue ─────────────────────────────────────────────
|
||||
q_parsing[["stonks:queue:parsing"]]
|
||||
ingestion -->|"rpush<br/>(news, filings,<br/>web_scrape)"| q_parsing
|
||||
ingestion -->|"rpush<br/>(news, filings,<br/>web_scrape, macro)"| q_parsing
|
||||
|
||||
%% ── Parser Worker ─────────────────────────────────────────────
|
||||
parser["<b>Parser</b><br/><i>services.parser.worker</i><br/>HTML parsing, quality scoring,<br/>company mention detection"]
|
||||
@@ -50,7 +50,7 @@ flowchart TB
|
||||
q_parsing -->|"lpop"| parser
|
||||
|
||||
minio_norm[("MinIO<br/><i>Normalized Text</i><br/><i>Parser Output JSON</i>")]
|
||||
parser -->|"upload normalized text"| minio_norm
|
||||
parser -->|"upload normalized text<br/>+ structured output"| minio_norm
|
||||
parser -->|"update document status,<br/>insert mentions"| pg_docs
|
||||
```
|
||||
|
||||
@@ -70,18 +70,23 @@ flowchart TB
|
||||
parser -->|"rpush<br/>(standard docs)"| q_extraction
|
||||
parser -->|"rpush<br/>(macro_event docs)"| q_macro
|
||||
|
||||
%% ── Scheduler Recovery ────────────────────────────────────────
|
||||
scheduler_recovery(("Scheduler<br/><i>stale recovery &<br/>failed retry</i>"))
|
||||
scheduler_recovery -.->|"re-enqueue orphaned<br/>parsed docs"| q_extraction
|
||||
scheduler_recovery -.->|"re-enqueue orphaned<br/>macro docs"| q_macro
|
||||
|
||||
%% ── Extractor Worker ──────────────────────────────────────────
|
||||
subgraph extractor_svc ["Extractor Service"]
|
||||
direction TB
|
||||
ext_main["<b>Extractor</b><br/><i>services.extractor.main</i><br/>Alternates between queues<br/>(2 extraction : 1 macro)"]
|
||||
ext_main["<b>Extractor</b><br/><i>services.extractor.main</i><br/>Alternates between queues<br/>(2 extraction : 1 macro)<br/>Token budget enforcement"]
|
||||
end
|
||||
|
||||
q_extraction -->|"lpop"| ext_main
|
||||
q_macro -->|"lpop"| ext_main
|
||||
|
||||
%% ── Ollama LLM ───────────────────────────────────────────────
|
||||
ollama["<b>Ollama</b><br/><i>LLM Inference</i><br/>document-extractor agent<br/>event-classifier agent"]
|
||||
ext_main <-->|"HTTP /api/generate"| ollama
|
||||
ollama["<b>Ollama / vLLM</b><br/><i>LLM Inference</i><br/>document-extractor agent<br/>event-classifier agent"]
|
||||
ext_main <-->|"HTTP /api/generate<br/>(AgentConfigResolver<br/>selects model + variant)"| ollama
|
||||
|
||||
%% ── Signal Layer 1: Company ───────────────────────────────────
|
||||
subgraph layer1 ["Layer 1 — Company Signals"]
|
||||
@@ -95,7 +100,7 @@ flowchart TB
|
||||
subgraph layer2 ["Layer 2 — Macro Signals"]
|
||||
direction LR
|
||||
ge["global_events"]
|
||||
mir["macro_impact_records<br/><i>per-company interpolation</i>"]
|
||||
mir["macro_impact_records<br/><i>per-company interpolation<br/>via exposure profiles</i>"]
|
||||
ge --> mir
|
||||
end
|
||||
|
||||
@@ -106,6 +111,10 @@ flowchart TB
|
||||
q_agg[["stonks:queue:aggregation"]]
|
||||
ext_main -->|"rpush<br/>(per ticker)"| q_agg
|
||||
|
||||
%% ── Scheduler Periodic Aggregation ────────────────────────────
|
||||
scheduler_agg(("Scheduler<br/><i>periodic aggregation<br/>every ~15 min</i>"))
|
||||
scheduler_agg -.->|"rpush all<br/>active tickers"| q_agg
|
||||
|
||||
%% ── Aggregation Worker ────────────────────────────────────────
|
||||
aggregation["<b>Aggregation</b><br/><i>services.aggregation.main</i><br/>Trend windows, scoring,<br/>contradiction detection"]
|
||||
|
||||
@@ -133,6 +142,8 @@ flowchart TB
|
||||
|
||||
## Recommendation → Trading → Broker
|
||||
|
||||
The recommendation worker consumes from the recommendation queue. The trading engine does **not** consume from a queue — it polls the `recommendations` table in PostgreSQL on a configurable interval, evaluates each recommendation through its decision pipeline, and pushes "act" decisions to the broker queue.
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
%% ── Recommendation Queue ──────────────────────────────────────
|
||||
@@ -144,19 +155,23 @@ flowchart TB
|
||||
|
||||
q_rec -->|"lpop"| recommendation
|
||||
|
||||
ollama_thesis["<b>Ollama</b><br/><i>thesis-rewriter agent</i><br/>(optional LLM rewrite)"]
|
||||
ollama_thesis["<b>Ollama / vLLM</b><br/><i>thesis-rewriter agent</i><br/>(AgentConfigResolver<br/>selects model + variant)"]
|
||||
recommendation <-->|"rewrite thesis<br/>(trading-eligible only)"| ollama_thesis
|
||||
|
||||
pg_recs[("PostgreSQL<br/><i>recommendations,<br/>recommendation_evidence,<br/>risk_evaluations</i>")]
|
||||
recommendation -->|"persist recommendation<br/>+ evidence + risk eval"| pg_recs
|
||||
|
||||
%% ── Lake Publication (inline) ─────────────────────────────────
|
||||
minio_rec_lake[("MinIO<br/><i>Lakehouse</i><br/>recommendation facts")]
|
||||
recommendation -->|"publish_recommendation_facts<br/>(Parquet)"| minio_rec_lake
|
||||
|
||||
%% ── Trading Engine ────────────────────────────────────────────
|
||||
subgraph trading_loop ["Trading Engine Decision Loop"]
|
||||
direction TB
|
||||
poll["Poll recommendations<br/><i>action IN (buy, sell)<br/>mode IN (paper, live)<br/>generated_at > last_poll</i>"]
|
||||
dedup_check["Redis dedup check<br/><i>stonks:dedupe:trading:*</i>"]
|
||||
evaluate["evaluate_recommendation<br/><i>Circuit breaker check<br/>Trading window check<br/>Confidence gate<br/>Sector exposure check<br/>Correlation check<br/>Earnings blackout</i>"]
|
||||
size["Position sizing<br/><i>Kelly criterion,<br/>risk tier limits</i>"]
|
||||
evaluate["evaluate_recommendation<br/><i>Circuit breaker check<br/>Trading window check<br/>Confidence gate<br/>Sector exposure check<br/>Correlation check<br/>Earnings blackout<br/>Max positions check</i>"]
|
||||
size["Position sizing<br/><i>Kelly criterion,<br/>risk tier limits,<br/>micro-trade support</i>"]
|
||||
decide{{"Decision"}}
|
||||
poll --> dedup_check --> evaluate --> size --> decide
|
||||
end
|
||||
@@ -170,22 +185,30 @@ flowchart TB
|
||||
|
||||
pg_decisions[("PostgreSQL<br/><i>trading_decisions</i>")]
|
||||
|
||||
%% ── Manual Override ───────────────────────────────────────────
|
||||
trading_api(("Trading API<br/><i>POST /override/order</i>"))
|
||||
trading_api -->|"rpush<br/>manual order"| q_broker
|
||||
|
||||
%% ── Broker Adapter ────────────────────────────────────────────
|
||||
broker["<b>Broker Adapter</b><br/><i>services.adapters.broker_service</i><br/>Risk evaluation, idempotency,<br/>order submission, fill tracking"]
|
||||
broker["<b>Broker Adapter</b><br/><i>services.adapters.broker_service</i><br/>Idempotency, risk evaluation,<br/>approval gate, order submission,<br/>fill tracking, position sync"]
|
||||
|
||||
q_broker -->|"lpop"| broker
|
||||
|
||||
%% ── Risk Engine ───────────────────────────────────────────────
|
||||
risk["<b>Risk Engine</b><br/><i>services.risk.app</i><br/>POST /evaluate<br/>Approval workflow"]
|
||||
broker <-->|"evaluate order"| risk
|
||||
risk["<b>Risk Engine</b><br/><i>services.risk.app</i><br/>evaluate_order()<br/>Position limits, sector exposure,<br/>daily loss caps, approval workflow"]
|
||||
broker -->|"evaluate order<br/>(inline call)"| risk
|
||||
|
||||
%% ── Alpaca ────────────────────────────────────────────────────
|
||||
alpaca["<b>Alpaca</b><br/><i>Paper Trading API</i><br/>Order submission,<br/>position sync"]
|
||||
broker <-->|"submit order /<br/>sync positions"| alpaca
|
||||
alpaca["<b>Alpaca</b><br/><i>Paper Trading API</i><br/>Order submission,<br/>position sync,<br/>account state"]
|
||||
broker <-->|"submit order /<br/>sync positions /<br/>sync order status"| alpaca
|
||||
|
||||
pg_orders[("PostgreSQL<br/><i>orders, order_events,<br/>positions,<br/>portfolio_snapshots</i>")]
|
||||
pg_orders[("PostgreSQL<br/><i>orders, order_events,<br/>positions,<br/>portfolio_snapshots,<br/>broker_accounts</i>")]
|
||||
broker -->|"persist order,<br/>events, positions"| pg_orders
|
||||
|
||||
%% ── Lake Publication (broker inline) ──────────────────────────
|
||||
minio_broker_lake[("MinIO<br/><i>Lakehouse</i><br/>order + fill + position facts")]
|
||||
broker -->|"publish_trade_order<br/>publish_trade_fill<br/>publish_positions_daily_batch<br/>(Parquet)"| minio_broker_lake
|
||||
|
||||
%% ── Notifications ─────────────────────────────────────────────
|
||||
subgraph notifications ["Notifications"]
|
||||
direction LR
|
||||
@@ -198,28 +221,32 @@ flowchart TB
|
||||
|
||||
## Analytical Branch — Lake Publisher
|
||||
|
||||
The lake publisher runs as a separate worker, consuming from its own queue and writing partitioned Parquet fact tables to MinIO for analytical queries.
|
||||
The lake publisher runs as a separate worker, consuming from its own queue and writing partitioned Parquet fact tables to MinIO for analytical queries. Some services (broker adapter, recommendation worker) also publish facts directly to MinIO inline, bypassing the queue.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
%% ── Lake Publish Queue ────────────────────────────────────────
|
||||
q_lake[["stonks:queue:lake_publish"]]
|
||||
|
||||
various(("Various Services<br/><i>ingestion, extractor,<br/>recommendation,<br/>broker adapter</i>"))
|
||||
various -->|"enqueue_lake_job"| q_lake
|
||||
various(("Upstream Services<br/><i>via enqueue_lake_job()</i>"))
|
||||
various -->|"rpush job<br/>(job_type + entity_id)"| q_lake
|
||||
|
||||
%% ── Lake Publisher Worker ─────────────────────────────────────
|
||||
lake["<b>Lake Publisher</b><br/><i>services.lake_publisher.jobs</i><br/>Transforms operational data<br/>into analytical facts"]
|
||||
lake["<b>Lake Publisher</b><br/><i>services.lake_publisher.jobs</i><br/>Transforms operational data<br/>into analytical facts<br/><i>15 job types supported</i>"]
|
||||
|
||||
q_lake -->|"lpop"| lake
|
||||
|
||||
pg_source[("PostgreSQL<br/><i>Operational Tables</i><br/>documents, extractions,<br/>orders, positions, events")]
|
||||
pg_source[("PostgreSQL<br/><i>Operational Tables</i><br/>documents, extractions,<br/>orders, positions, events,<br/>global_events, macro_impacts,<br/>competitive_signals")]
|
||||
lake -->|"query source data"| pg_source
|
||||
|
||||
%% ── MinIO Parquet ─────────────────────────────────────────────
|
||||
minio_lake[("MinIO<br/><i>Lakehouse Bucket</i><br/>Partitioned Parquet<br/>/year=/month=/day=")]
|
||||
lake -->|"write Parquet files"| minio_lake
|
||||
|
||||
%% ── Inline Publishers ─────────────────────────────────────────
|
||||
inline(("Inline Publishers<br/><i>broker adapter,<br/>recommendation worker</i>"))
|
||||
inline -->|"publish_* functions<br/>(direct Parquet write)"| minio_lake
|
||||
|
||||
%% ── Trino ─────────────────────────────────────────────────────
|
||||
trino["<b>Trino</b><br/><i>SQL Query Engine</i><br/>Hive connector → MinIO"]
|
||||
minio_lake -->|"read via<br/>Hive Metastore"| trino
|
||||
@@ -238,18 +265,40 @@ flowchart LR
|
||||
query_api --> dashboard
|
||||
```
|
||||
|
||||
## Report Generation
|
||||
|
||||
The scheduler manages report generation as a sub-loop, enqueuing daily and weekly report jobs to a dedicated queue and consuming them inline.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
scheduler["<b>Scheduler</b><br/><i>report schedule check</i><br/>daily @ 16:30 ET<br/>weekly @ Saturday"]
|
||||
|
||||
q_report[["stonks:queue:report_generation"]]
|
||||
scheduler -->|"rpush<br/>(daily/weekly)"| q_report
|
||||
|
||||
scheduler_consumer["<b>Scheduler</b><br/><i>report consumer loop</i><br/>pops up to 5 jobs/cycle"]
|
||||
q_report -->|"lpop"| scheduler_consumer
|
||||
|
||||
generator["<b>Report Generator</b><br/><i>services.reporting.generator</i>"]
|
||||
scheduler_consumer -->|"process_report_job()"| generator
|
||||
|
||||
pg_reports[("PostgreSQL<br/><i>trading_reports</i>")]
|
||||
generator -->|"persist report"| pg_reports
|
||||
```
|
||||
|
||||
## Complete Queue Topology
|
||||
|
||||
| Queue | Full Key | Producer(s) | Consumer |
|
||||
|-------|----------|-------------|----------|
|
||||
| Ingestion | `stonks:queue:ingestion` | Scheduler | Ingestion Worker |
|
||||
| Parsing | `stonks:queue:parsing` | Ingestion Worker | Parser Worker |
|
||||
| Extraction | `stonks:queue:extraction` | Parser (standard docs) | Extractor Worker |
|
||||
| Macro Classification | `stonks:queue:macro_classification` | Parser (macro_event docs), Scheduler | Extractor Worker |
|
||||
| Aggregation | `stonks:queue:aggregation` | Extractor Worker | Aggregation Worker |
|
||||
| Recommendation | `stonks:queue:recommendation` | Aggregation Worker | Recommendation Worker |
|
||||
| Broker Orders | `stonks:queue:broker_orders` | Trading Engine, Trading API (manual overrides) | Broker Adapter |
|
||||
| Lake Publish | `stonks:queue:lake_publish` | Various services | Lake Publisher |
|
||||
| Ingestion | `stonks:queue:ingestion` | Scheduler (company, macro, global market sources) | Ingestion Worker |
|
||||
| Parsing | `stonks:queue:parsing` | Ingestion Worker (news, filings, web_scrape, macro) | Parser Worker |
|
||||
| Extraction | `stonks:queue:extraction` | Parser (standard docs), Scheduler (stale recovery) | Extractor Worker |
|
||||
| Macro Classification | `stonks:queue:macro_classification` | Parser (macro_event docs), Scheduler (stale/failed recovery) | Extractor Worker |
|
||||
| Aggregation | `stonks:queue:aggregation` | Extractor Worker (per ticker), Scheduler (periodic, all tickers) | Aggregation Worker |
|
||||
| Recommendation | `stonks:queue:recommendation` | Aggregation Worker (ticker + window, 5 min dedup TTL) | Recommendation Worker |
|
||||
| Broker Orders | `stonks:queue:broker_orders` | Trading Engine (act decisions), Trading API (manual overrides) | Broker Adapter |
|
||||
| Lake Publish | `stonks:queue:lake_publish` | Various services (via `enqueue_lake_job()`) | Lake Publisher |
|
||||
| Report Generation | `stonks:queue:report_generation` | Scheduler (daily/weekly triggers) | Scheduler (inline consumer) |
|
||||
|
||||
Dead-letter queues follow the pattern `stonks:dlq:<queue_name>` and are populated when a job exhausts its retry budget.
|
||||
|
||||
@@ -257,18 +306,25 @@ Dead-letter queues follow the pattern `stonks:dlq:<queue_name>` and are populate
|
||||
|
||||
| Store | Role | Key Tables / Buckets |
|
||||
|-------|------|---------------------|
|
||||
| **PostgreSQL** | Structured operational data | `documents`, `document_intelligence`, `document_impact_records`, `global_events`, `macro_impact_records`, `competitive_signal_records`, `trend_windows`, `trend_history`, `trend_projections`, `recommendations`, `recommendation_evidence`, `risk_evaluations`, `orders`, `order_events`, `positions`, `portfolio_snapshots`, `trading_decisions` |
|
||||
| **Redis** | Queues, dedup markers, rate limits, circuit breaker state | `stonks:queue:*`, `stonks:dedupe:*`, `stonks:ratelimit:*`, `stonks:trading:circuit_breaker:*`, `stonks:dlq:*` |
|
||||
| **MinIO** | Object storage for raw artifacts, normalized text, and analytical Parquet files | Raw artifacts bucket, normalized text bucket, lakehouse bucket (partitioned Parquet) |
|
||||
| **PostgreSQL** | Structured operational data | `documents`, `document_intelligence`, `document_impact_records`, `document_company_mentions`, `global_events`, `macro_impact_records`, `exposure_profiles`, `competitive_signal_records`, `competitor_relationships`, `trend_windows`, `trend_history`, `trend_projections`, `recommendations`, `recommendation_evidence`, `risk_evaluations`, `orders`, `order_events`, `positions`, `portfolio_snapshots`, `trading_decisions`, `circuit_breaker_events`, `reserve_pool_ledger`, `risk_tier_history`, `broker_accounts`, `ingestion_runs`, `sources`, `companies`, `company_aliases`, `ai_agents`, `agent_variants`, `agent_performance_log`, `risk_configs`, `trading_reports` |
|
||||
| **Redis** | Queues, dedup markers, rate limits, circuit breaker state, pipeline toggle | `stonks:queue:*` (9 queues), `stonks:dedupe:*`, `stonks:dedupe:trading:*`, `stonks:ratelimit:*`, `stonks:trading:circuit_breaker:*`, `stonks:trading:notification_rate:*`, `stonks:order_idempotency:*`, `stonks:lock:*`, `stonks:cache:*`, `stonks:retry:*`, `stonks:rec_dedup:*`, `stonks:pipeline:enabled`, `stonks:dlq:*` |
|
||||
| **MinIO** | Object storage for raw artifacts, normalized text, and analytical Parquet files | Raw artifacts bucket, normalized text bucket, parser output bucket, lakehouse bucket (partitioned Parquet: documents, extractions, market bars/quotes, orders, fills, positions, PnL, global events, macro impacts, trend projections, competitive signals, competitor relationships, recommendations) |
|
||||
|
||||
## External Integration Points
|
||||
|
||||
| Integration | Service | Protocol | Purpose |
|
||||
|-------------|---------|----------|---------|
|
||||
| **Polygon.io** | Ingestion (via adapters) | HTTPS REST | News articles, market bars, grouped daily data |
|
||||
| **SEC EDGAR** | Ingestion (via FilingsDataAdapter) | HTTPS REST | 10-K, 10-Q filings |
|
||||
| **Ollama** | Extractor, Recommendation | HTTP `/api/generate` | LLM inference for document extraction, event classification, thesis rewriting |
|
||||
| **Alpaca** | Broker Adapter | HTTPS REST | Paper trading order submission, position sync, account state |
|
||||
| **Polygon.io** | Ingestion (via PolygonNewsAdapter, PolygonMarketAdapter) | HTTPS REST | News articles, market bars, grouped daily data, intraday bars |
|
||||
| **SEC EDGAR** | Ingestion (via SECEdgarAdapter) | HTTPS REST | 10-K, 10-Q filings |
|
||||
| **Macro News** | Ingestion (via MacroNewsAdapter) | HTTPS REST | Geopolitical and economic event articles |
|
||||
| **Ollama / vLLM** | Extractor, Recommendation | HTTP `/api/generate` | LLM inference for document extraction (document-extractor agent), event classification (event-classifier agent), thesis rewriting (thesis-rewriter agent). Model and variant selected via `AgentConfigResolver` with 60s TTL cache. |
|
||||
| **Alpaca** | Broker Adapter | HTTPS REST | Paper/live trading: order submission, position sync, account state, order status polling |
|
||||
| **AWS SNS** | Trading Engine (notifications) | boto3 SDK | SMS alerts for circuit breaker trips, order fills, stop-loss triggers |
|
||||
| **Gmail** | Trading Engine (notifications) | SMTP (port 587 STARTTLS) | Email alerts for trading events |
|
||||
| **Trino** | Query API, Superset | JDBC / HTTP | SQL queries over lakehouse Parquet files |
|
||||
| **Trino** | Query API, Superset | HTTP | SQL queries over lakehouse Parquet files via Hive Metastore |
|
||||
|
||||
## Pipeline Toggle
|
||||
|
||||
The pipeline can be paused globally via the Redis key `stonks:pipeline:enabled`. When set to `"0"`, all queue workers (ingestion, parser, extractor, aggregation, recommendation, broker adapter, lake publisher) enter a sleep loop and stop processing jobs. The scheduler also skips scheduling cycles when the toggle is off. The toggle can be set via the Query API's pipeline control endpoints.
|
||||
|
||||
Setting `PIPELINE_DEFAULT_OFF=true` on the scheduler initializes the toggle to OFF on first boot, useful for staged deployments where you want to verify infrastructure before enabling the pipeline.
|
||||
|
||||
@@ -53,7 +53,7 @@ graph TB
|
||||
subgraph trading_tier ["Trading Tier"]
|
||||
direction LR
|
||||
trading_engine["trading-engine<br/><i>docker/Dockerfile</i><br/><i>uvicorn services.trading.app</i><br/>host :8002 → :8000"]
|
||||
risk_engine["risk-engine<br/><i>docker/Dockerfile</i><br/><i>uvicorn services.risk.app</i><br/>host :8003 → :8000"]
|
||||
risk_engine["risk-engine<br/><i>docker/Dockerfile</i><br/><i>uvicorn services.risk.app</i><br/>host :8003 → :8000<br/><i>alias: risk</i>"]
|
||||
broker_adapter["broker-adapter<br/><i>docker/Dockerfile</i><br/><i>python -m services.adapters.broker_service</i><br/><i>no host port</i>"]
|
||||
end
|
||||
|
||||
@@ -320,3 +320,4 @@ All containers share the default Docker Compose network. Services reference each
|
||||
| `hive-metastore` | Hive Metastore container | trino (thrift://hive-metastore:9083) |
|
||||
| `trino` | Trino container | superset (trino:8080) |
|
||||
| `query-api` | Query API container | dashboard (nginx proxy upstream) |
|
||||
| `risk` | risk-engine container (network alias) | trading-engine (risk evaluation calls) |
|
||||
|
||||
@@ -11,7 +11,7 @@ graph TB
|
||||
%% ── External traffic ──────────────────────────────────────────
|
||||
internet((Internet))
|
||||
|
||||
subgraph traefik ["kube-system (Traefik Ingress Controller)"]
|
||||
subgraph traefik ["kube-system · Traefik Ingress Controller"]
|
||||
direction LR
|
||||
ing_dash["stonks.celestium.life"]
|
||||
ing_api["stonks-api.celestium.life"]
|
||||
@@ -28,47 +28,55 @@ graph TB
|
||||
direction TB
|
||||
|
||||
%% ── API Tier (ingress-facing) ─────────────────────────────
|
||||
subgraph api_tier ["API Tier"]
|
||||
subgraph api_tier ["API Tier · tier: api"]
|
||||
direction LR
|
||||
query_api["query-api<br/><i>Deployment (1 replica)</i><br/>:8000"]
|
||||
symbol_registry["symbol-registry<br/><i>Deployment (1 replica)</i><br/>:8000"]
|
||||
query_api["query-api<br/><i>Deployment · 1 replica</i><br/>:8000<br/><i>readiness: /docs</i>"]
|
||||
symbol_registry["symbol-registry<br/><i>Deployment · 1 replica</i><br/>:8000<br/><i>readiness: /docs · liveness: /docs</i>"]
|
||||
end
|
||||
|
||||
%% ── Frontend Tier ─────────────────────────────────────────
|
||||
subgraph frontend_tier ["Frontend Tier"]
|
||||
dashboard["dashboard<br/><i>Deployment (1 replica)</i><br/>:8080<br/><i>nginx-unprivileged</i>"]
|
||||
subgraph frontend_tier ["Frontend Tier · tier: frontend"]
|
||||
dashboard["dashboard<br/><i>Deployment · 1 replica</i><br/>:8080<br/><i>nginx-unprivileged</i><br/><i>readiness: / · liveness: /</i>"]
|
||||
end
|
||||
|
||||
%% ── Trading Tier ──────────────────────────────────────────
|
||||
subgraph trading_tier ["Trading Tier"]
|
||||
subgraph trading_tier ["Trading Tier · tier: trading"]
|
||||
direction LR
|
||||
trading_engine["trading-engine<br/><i>Deployment (1 replica)</i><br/>:8000"]
|
||||
risk_engine["risk-engine<br/><i>Deployment (1 replica)</i><br/>:8000"]
|
||||
broker_adapter["broker-adapter<br/><i>Deployment (1 replica)</i><br/><i>queue-driven worker</i>"]
|
||||
trading_engine["trading-engine<br/><i>Deployment · 1 replica</i><br/>:8000<br/><i>readiness: /ready · liveness: /health</i>"]
|
||||
risk_engine["risk-engine<br/><i>Deployment · 1 replica</i><br/>:8000"]
|
||||
broker_adapter["broker-adapter<br/><i>Deployment · 1 replica</i><br/><i>queue-driven worker · pipeline-gated</i>"]
|
||||
end
|
||||
|
||||
%% ── Orchestration Tier ────────────────────────────────────
|
||||
subgraph orchestration_tier ["Orchestration Tier"]
|
||||
scheduler["scheduler<br/><i>Deployment (1 replica)</i><br/><i>runs migrations + seed</i>"]
|
||||
subgraph orchestration_tier ["Orchestration Tier · tier: orchestration"]
|
||||
scheduler["scheduler<br/><i>Deployment · 1 replica · pipeline-gated</i><br/><i>init: migrations → seed → backfill</i>"]
|
||||
end
|
||||
|
||||
%% ── Ingestion Tier ────────────────────────────────────────
|
||||
subgraph ingestion_tier ["Ingestion Tier · tier: ingestion"]
|
||||
ingestion["ingestion<br/><i>Deployment · 1 replica · pipeline-gated</i><br/><i>queue-driven worker</i>"]
|
||||
end
|
||||
|
||||
%% ── Processing Tier (pipeline workers) ────────────────────
|
||||
subgraph processing_tier ["Processing Tier (pipeline workers)"]
|
||||
subgraph processing_tier ["Processing Tier · tier: processing"]
|
||||
direction LR
|
||||
ingestion["ingestion<br/><i>Deployment (2 replicas)</i>"]
|
||||
parser["parser<br/><i>Deployment (2 replicas)</i>"]
|
||||
extractor["extractor<br/><i>Deployment (1 replica)</i>"]
|
||||
aggregation["aggregation<br/><i>Deployment (4 replicas)</i>"]
|
||||
recommendation["recommendation<br/><i>Deployment (1 replica)</i>"]
|
||||
parser["parser<br/><i>Deployment · 2 replicas · pipeline-gated</i>"]
|
||||
extractor["extractor<br/><i>Deployment · 1 replica · pipeline-gated</i>"]
|
||||
aggregation["aggregation<br/><i>Deployment · 4 replicas · pipeline-gated</i>"]
|
||||
recommendation["recommendation<br/><i>Deployment · 1 replica · pipeline-gated</i>"]
|
||||
end
|
||||
|
||||
%% ── Analytics Tier ────────────────────────────────────────
|
||||
subgraph analytics_tier ["Analytics Tier"]
|
||||
subgraph analytics_tier ["Analytics Tier · tier: analytics"]
|
||||
direction LR
|
||||
lake_publisher["lake-publisher<br/><i>Deployment (1 replica)</i><br/><i>queue-driven worker</i>"]
|
||||
hive_metastore["hive-metastore<br/><i>Deployment (1 replica)</i><br/>:9083<br/><i>apache/hive:4.0.0</i>"]
|
||||
trino["trino<br/><i>Deployment (1 replica)</i><br/>:8080<br/><i>trinodb/trino:latest</i>"]
|
||||
superset["superset<br/><i>Deployment (1 replica)</i><br/>:8088<br/><i>custom image</i>"]
|
||||
lake_publisher["lake-publisher<br/><i>Deployment · 1 replica · pipeline-gated</i><br/><i>queue-driven worker</i>"]
|
||||
hive_metastore["hive-metastore<br/><i>Deployment · 1 replica</i><br/>:9083<br/><i>apache/hive:4.0.0</i><br/><i>PVC: hive-metastore-data</i>"]
|
||||
trino["trino<br/><i>Deployment · 1 replica</i><br/>:8080<br/><i>trinodb/trino:latest</i><br/><i>readiness: /v1/info</i>"]
|
||||
end
|
||||
|
||||
%% ── Superset (tier: dashboard in template) ────────────────
|
||||
subgraph superset_block ["Superset · tier: dashboard"]
|
||||
superset["superset<br/><i>Deployment · 1 replica</i><br/>:8088<br/><i>custom image</i><br/><i>PVC: superset-data</i><br/><i>readiness: /health</i>"]
|
||||
end
|
||||
|
||||
%% ── Helm Secrets ──────────────────────────────────────────
|
||||
@@ -99,7 +107,7 @@ graph TB
|
||||
end
|
||||
|
||||
subgraph ollama_ns ["ollama-service namespace"]
|
||||
ollama[("Ollama<br/>ollama:11434<br/><i>GPU: 4070 Ti Super</i>")]
|
||||
ollama[("Ollama<br/>ollama:11434<br/><i>GPU: 4070 Ti Super 16GB</i>")]
|
||||
end
|
||||
|
||||
%% ── Ingress Routes ────────────────────────────────────────────
|
||||
@@ -191,6 +199,7 @@ graph TB
|
||||
sec_broker -.-> broker_adapter
|
||||
|
||||
sec_market -.-> ingestion
|
||||
sec_market -.-> query_api
|
||||
|
||||
sec_gmail -.-> trading_engine
|
||||
|
||||
@@ -216,7 +225,9 @@ graph TB
|
||||
classDef tradingSvc fill:#e8a838,stroke:#b07d1a,color:#fff
|
||||
classDef processSvc fill:#9b59b6,stroke:#6c3483,color:#fff
|
||||
classDef orchSvc fill:#1abc9c,stroke:#148f77,color:#fff
|
||||
classDef ingestionSvc fill:#e67e22,stroke:#bf6516,color:#fff
|
||||
classDef analyticsSvc fill:#e74c3c,stroke:#a93226,color:#fff
|
||||
classDef supersetSvc fill:#c0392b,stroke:#96281b,color:#fff
|
||||
classDef extSvc fill:#95a5a6,stroke:#717d7e,color:#fff
|
||||
classDef secretSvc fill:#f5f5dc,stroke:#999,color:#333
|
||||
classDef configSvc fill:#dfe6e9,stroke:#999,color:#333
|
||||
@@ -225,8 +236,10 @@ graph TB
|
||||
class dashboard frontendSvc
|
||||
class trading_engine,risk_engine,broker_adapter tradingSvc
|
||||
class scheduler orchSvc
|
||||
class ingestion,parser,extractor,aggregation,recommendation processSvc
|
||||
class lake_publisher,hive_metastore,trino,superset analyticsSvc
|
||||
class ingestion ingestionSvc
|
||||
class parser,extractor,aggregation,recommendation processSvc
|
||||
class lake_publisher,hive_metastore,trino analyticsSvc
|
||||
class superset supersetSvc
|
||||
class postgres,redis,minio,ollama extSvc
|
||||
class sec_core,sec_broker,sec_market,sec_gmail,sec_dashboard secretSvc
|
||||
class configmap configSvc
|
||||
@@ -284,8 +297,8 @@ The following services have **no inbound network policy** — they are queue-dri
|
||||
|
||||
| Service | Tier | Behavior |
|
||||
|---------|------|----------|
|
||||
| scheduler | orchestration | Polls DB, enqueues to Redis |
|
||||
| ingestion | processing | Reads from `stonks:queue:ingestion`, writes to DB/MinIO/Redis |
|
||||
| scheduler | orchestration | Polls DB, enqueues to Redis. Runs migrations + seed + backfill as init containers |
|
||||
| ingestion | ingestion | Reads from `stonks:queue:ingestion`, writes to DB/MinIO/Redis. Egress to Polygon.io/News APIs |
|
||||
| parser | processing | Reads from `stonks:queue:parsing`, writes to DB/Redis |
|
||||
| extractor | processing | Reads from `stonks:queue:extraction`, calls Ollama, writes to DB/Redis |
|
||||
| aggregation | processing | Reads from `stonks:queue:aggregation`, writes to DB/Redis |
|
||||
@@ -294,22 +307,24 @@ The following services have **no inbound network policy** — they are queue-dri
|
||||
|
||||
## Service Tier Summary
|
||||
|
||||
| Tier | Services | Ingress? | Replicas | Notes |
|
||||
|------|----------|----------|----------|-------|
|
||||
| **api** | query-api, symbol-registry | Yes (Traefik) | 1 each | FastAPI, readiness probes on `/docs` |
|
||||
| **frontend** | dashboard | Yes (Traefik) | 1 | nginx-unprivileged on :8080, proxies to API services |
|
||||
| **trading** | trading-engine, risk-engine, broker-adapter | trading-engine: Yes; risk-engine: internal only; broker-adapter: denied | 1 each | trading-engine has egress to Alpaca + Gmail |
|
||||
| **orchestration** | scheduler | No | 1 | Runs DB migrations + seed as init containers |
|
||||
| **processing** | ingestion, parser, extractor, aggregation, recommendation | No | 2, 2, 1, 4, 1 | Pipeline-gated by `pipelineEnabled` toggle |
|
||||
| **analytics** | lake-publisher, trino, hive-metastore, superset | trino + superset: Yes; others: No | 1 each | lake-publisher is pipeline-gated |
|
||||
| Tier | Services | Ingress? | Replicas | Pipeline-Gated? | Notes |
|
||||
|------|----------|----------|----------|-----------------|-------|
|
||||
| **api** | query-api, symbol-registry | Yes (Traefik) | 1 each | No | FastAPI, readiness probes on `/docs` |
|
||||
| **frontend** | dashboard | Yes (Traefik) | 1 | No | nginx-unprivileged on :8080, proxies to API services |
|
||||
| **trading** | trading-engine, risk-engine, broker-adapter | trading-engine: Yes; risk-engine: internal only; broker-adapter: denied | 1 each | broker-adapter only | trading-engine has egress to Alpaca + Gmail |
|
||||
| **orchestration** | scheduler | No | 1 | Yes | Runs DB migrations + seed + backfill as init containers |
|
||||
| **ingestion** | ingestion | No | 1 | Yes | Fetches from external APIs (Polygon.io, news, filings) |
|
||||
| **processing** | parser, extractor, aggregation, recommendation | No | 2, 1, 4, 1 | Yes | Queue-driven pipeline workers |
|
||||
| **analytics** | lake-publisher, trino, hive-metastore | trino: Yes (Traefik); others: No | 1 each | lake-publisher only | trino + hive-metastore gated by `trino.enabled` / `hiveMetastore.enabled` |
|
||||
| **dashboard** (Superset) | superset | Yes (Traefik) | 1 | No | Gated by `superset.enabled`, custom image with trino + psycopg2 drivers |
|
||||
|
||||
## Secret Consumption Map
|
||||
|
||||
| Secret | Keys | Consumers |
|
||||
|--------|------|-----------|
|
||||
| `stonks-core-secrets` | POSTGRES_PASSWORD, MINIO_ACCESS_KEY, MINIO_SECRET_KEY, REDIS_PASSWORD | All 13 app services + hive-metastore, trino, superset |
|
||||
| `stonks-core-secrets` | POSTGRES_PASSWORD, MINIO_ACCESS_KEY, MINIO_SECRET_KEY, REDIS_PASSWORD | All 13 app services + hive-metastore (init), trino (init), superset |
|
||||
| `stonks-broker-secrets` | BROKER_API_KEY, BROKER_API_SECRET, BROKER_BASE_URL | ingestion, trading-engine, risk-engine, broker-adapter |
|
||||
| `stonks-market-secrets` | MARKET_DATA_API_KEY | ingestion |
|
||||
| `stonks-market-secrets` | MARKET_DATA_API_KEY | ingestion, query-api |
|
||||
| `stonks-gmail-secrets` | GMAIL_SENDER, GMAIL_RECIPIENT, GMAIL_APP_PASSWORD | trading-engine |
|
||||
| `stonks-dashboard-secrets` | SUPERSET_SECRET_KEY, SUPERSET_ADMIN_PASSWORD | superset |
|
||||
|
||||
@@ -336,10 +351,10 @@ These services run outside the `stonks-oracle` namespace and are referenced via
|
||||
|
||||
The analytics stack runs within the `stonks-oracle` namespace:
|
||||
|
||||
1. **Lake Publisher** writes Parquet fact tables to MinIO at `s3a://stonks-lakehouse/warehouse`
|
||||
2. **Hive Metastore** (Apache Hive 4.0.0) manages table metadata, backed by embedded Derby DB with a PVC for persistence. Connects to MinIO for S3A filesystem access.
|
||||
3. **Trino** queries the lakehouse via Hive Metastore (thrift://hive-metastore:9083). Exposes two catalogs: `lakehouse` (Hive connector) and `iceberg` (Iceberg connector). Both connect to MinIO for data access.
|
||||
4. **Superset** connects to Trino for lakehouse queries and to PostgreSQL for its metadata DB. Uses Redis for caching. Exposed externally via Traefik ingress.
|
||||
1. **Lake Publisher** writes Parquet fact tables to MinIO at `s3a://stonks-lakehouse/warehouse`. Pipeline-gated — scales to 0 when `pipelineEnabled: false`.
|
||||
2. **Hive Metastore** (Apache Hive 4.0.0) manages table metadata, backed by embedded Derby DB with a PVC (`hive-metastore-data`) for persistence. Connects to MinIO for S3A filesystem access. Gated by `hiveMetastore.enabled`.
|
||||
3. **Trino** queries the lakehouse via Hive Metastore (`thrift://hive-metastore:9083`). Exposes two catalogs: `lakehouse` (Hive connector) and `iceberg` (Iceberg connector). Both connect to MinIO for data access. Gated by `trino.enabled`. Readiness probe on `/v1/info`.
|
||||
4. **Superset** connects to Trino for lakehouse queries and to PostgreSQL for its metadata DB. Uses Redis for caching. Exposed externally via Traefik ingress. Gated by `superset.enabled`. Uses custom image (`registry.celestium.life/stonks-oracle/superset:latest`) with trino + psycopg2 drivers. PVC (`superset-data`) for persistence.
|
||||
|
||||
## Ingress Routes
|
||||
|
||||
@@ -353,3 +368,13 @@ All ingress resources use the `traefik` IngressClass with TLS certificates issue
|
||||
| `stonks-trading.celestium.life` | trading-engine | 8000 | `stonks-trading-tls` |
|
||||
| `stonks-dash.celestium.life` | superset | 8088 | `stonks-dash-tls` |
|
||||
| `stonks-trino.celestium.life` | trino | 8080 | `stonks-trino-tls` |
|
||||
|
||||
## Deployment Stages
|
||||
|
||||
The Helm chart supports multiple deployment stages via value override files:
|
||||
|
||||
| Stage | Override File | Namespace | Key Differences |
|
||||
|-------|--------------|-----------|-----------------|
|
||||
| **Production** | `values.yaml` (base) | `stonks-oracle` | Full analytics stack, all services |
|
||||
| **Paper** | `values-paper.yaml` | `stonks-oracle` | `BROKER_MODE=paper`, `DEPLOY_STAGE=paper`, separate DB (`stonks_paper`), Redis DB 2, paper-specific ingress hostnames |
|
||||
| **Beta** | `values-beta.yaml` | `stonks-oracle-beta` | `DEPLOY_STAGE=beta`, `LOG_LEVEL=DEBUG`, separate DB (`stonks_beta`), Redis DB 1, analytics stack disabled, beta-specific ingress hostnames |
|
||||
|
||||
+284
-15
@@ -5,6 +5,7 @@ This guide covers running the full Stonks Oracle platform locally using Docker C
|
||||
## Prerequisites
|
||||
|
||||
- Docker Engine 24+ and Docker Compose v2
|
||||
- NVIDIA GPU with drivers and NVIDIA Container Toolkit (for Ollama LLM inference)
|
||||
- At least 16 GB RAM (Ollama + Trino + all services)
|
||||
- API keys for Polygon.io and Alpaca (optional — platform runs in degraded mode without them)
|
||||
|
||||
@@ -14,20 +15,54 @@ This guide covers running the full Stonks Oracle platform locally using Docker C
|
||||
# 1. Clone the repository
|
||||
git clone <repo-url> && cd stonks-oracle
|
||||
|
||||
# 2. Configure API keys
|
||||
cp .env.example .env # or edit the existing .env
|
||||
# Fill in MARKET_DATA_API_KEY, BROKER_API_KEY, BROKER_API_SECRET
|
||||
# 2. Configure API keys (create .env in the repo root)
|
||||
cat > .env <<'EOF'
|
||||
MARKET_DATA_API_KEY=your_polygon_key
|
||||
BROKER_API_KEY=your_alpaca_key
|
||||
BROKER_API_SECRET=your_alpaca_secret
|
||||
BROKER_BASE_URL=https://paper-api.alpaca.markets
|
||||
EOF
|
||||
|
||||
# 3. Start everything
|
||||
docker compose up -d
|
||||
|
||||
# 4. Verify all services are healthy
|
||||
# 4. Pull an LLM model into Ollama
|
||||
docker compose exec ollama ollama pull qwen3.5:9b-fast
|
||||
|
||||
# 5. Seed the database
|
||||
docker compose exec scheduler python -m services.symbol_registry.seed
|
||||
|
||||
# 6. Verify all services are healthy
|
||||
docker compose ps
|
||||
|
||||
# 5. Access the dashboard
|
||||
# 7. Access the dashboard
|
||||
open http://localhost:3000
|
||||
```
|
||||
|
||||
### Automated Deployment
|
||||
|
||||
The `deploy-docker.sh` script automates the full deployment to a remote host via SSH, including prerequisite installation, repository sync, environment configuration, image builds, service startup, database seeding, and Ollama model pulling:
|
||||
|
||||
```bash
|
||||
# Deploy with defaults (GPU-accelerated Docker Ollama)
|
||||
bash deploy-docker.sh
|
||||
|
||||
# Specify a custom Ollama model
|
||||
bash deploy-docker.sh --ollama-model qwen3.6
|
||||
|
||||
# Deploy to a different host
|
||||
bash deploy-docker.sh --host user@myserver --dir /opt/stonks
|
||||
```
|
||||
|
||||
| Flag | Default | Description |
|
||||
|------|---------|-------------|
|
||||
| `--host` | `celes@192.168.42.254` | SSH target (`USER@HOST`) |
|
||||
| `--ollama-url` | (auto — Docker container) | Ollama API URL |
|
||||
| `--ollama-model` | `qwen3.5:9b-fast` | Ollama model to pull |
|
||||
| `--dir` | `~/stonks-oracle` | Remote install directory |
|
||||
|
||||
The script detects the target OS and package manager (apt, dnf, yum, pacman, zypper) and installs Docker, NVIDIA drivers, and the NVIDIA Container Toolkit as needed. It also handles WSL environments and firewall configuration.
|
||||
|
||||
---
|
||||
|
||||
## Service Inventory
|
||||
@@ -63,6 +98,8 @@ open http://localhost:3000
|
||||
| `query-api` | `docker/Dockerfile` | `uvicorn services.api.app:app --host 0.0.0.0 --port 8000` | `8004:8000` | postgres (healthy), redis (healthy), minio (healthy) |
|
||||
| `dashboard` | `frontend/Dockerfile` | nginx (built-in) | `3000:8080` | query-api (healthy) |
|
||||
|
||||
The `risk-engine` service has a Docker network alias of `risk` so the dashboard's nginx reverse proxy can resolve it as `http://risk:8000`.
|
||||
|
||||
### Port Summary
|
||||
|
||||
| Port | Service | Protocol |
|
||||
@@ -109,15 +146,27 @@ The `.env` file is loaded by `ingestion`, `broker-adapter`, and `trading-engine`
|
||||
|
||||
```dotenv
|
||||
# Stonks Oracle — Environment Variables
|
||||
# These are loaded by ingestion, broker-adapter, and trading-engine services.
|
||||
# Loaded by: ingestion, broker-adapter, trading-engine
|
||||
|
||||
# Polygon.io market data API key (required for live data ingestion)
|
||||
# ── Required for live data ingestion ──
|
||||
MARKET_DATA_API_KEY=
|
||||
|
||||
# Alpaca broker credentials (required for paper/live trading)
|
||||
# ── Required for paper/live trading ──
|
||||
BROKER_API_KEY=
|
||||
BROKER_API_SECRET=
|
||||
BROKER_BASE_URL=https://paper-api.alpaca.markets
|
||||
|
||||
# ── Trading engine settings (optional) ──
|
||||
TRADING_ENABLED=true
|
||||
TRADING_RISK_TIER=moderate
|
||||
TRADING_MAX_OPEN_POSITIONS=15
|
||||
|
||||
# ── LLM model (optional) ──
|
||||
OLLAMA_MODEL=qwen3.5:9b-fast
|
||||
|
||||
# ── Signal layers (optional) ──
|
||||
MACRO_ENABLED=true
|
||||
COMPETITIVE_ENABLED=true
|
||||
```
|
||||
|
||||
| Variable | Required | Default | Used By | Description |
|
||||
@@ -181,10 +230,21 @@ All application services support additional environment variables loaded via `se
|
||||
| `OLLAMA_MODEL` | `qwen3.5:9b` | Default LLM model for extraction |
|
||||
| `OLLAMA_TIMEOUT` | `120` | Ollama request timeout (seconds) |
|
||||
| `OLLAMA_MAX_RETRIES` | `2` | Max retries for Ollama requests |
|
||||
| `OLLAMA_RETRY_BASE_DELAY` | `1.0` | Base delay between retries (seconds) |
|
||||
| `OLLAMA_RETRY_MAX_DELAY` | `10.0` | Maximum delay between retries (seconds) |
|
||||
| `OLLAMA_RETRY_BACKOFF_MULTIPLIER` | `2.0` | Backoff multiplier for retries |
|
||||
| `VLLM_BASE_URL` | `http://192.168.42.254:8000` | vLLM server URL (if using vLLM instead of Ollama) |
|
||||
| `VLLM_MODEL` | `RedHatAI/Qwen3.6-35B-A3B-NVFP4` | vLLM model name |
|
||||
| `VLLM_TIMEOUT` | `120` | vLLM request timeout (seconds) |
|
||||
| `VLLM_MAX_RETRIES` | `2` | Max retries for vLLM requests |
|
||||
| `VLLM_TEMPERATURE` | `0.7` | vLLM sampling temperature |
|
||||
| `VLLM_MAX_TOKENS` | `4096` | vLLM max output tokens |
|
||||
| `VLLM_API_KEY` | (empty) | vLLM API key (if required) |
|
||||
| `TRINO_HOST` | `localhost` | Trino hostname |
|
||||
| `TRINO_PORT` | `8080` | Trino port |
|
||||
| `TRINO_CATALOG` | `lakehouse` | Trino catalog name |
|
||||
| `TRINO_SCHEMA` | `stonks` | Trino schema name |
|
||||
| `TRINO_ICEBERG_CATALOG` | `iceberg` | Trino Iceberg catalog name |
|
||||
| `MARKET_DATA_BASE_URL` | `https://api.polygon.io` | Polygon.io base URL |
|
||||
| `MARKET_DATA_PROVIDER` | `polygon` | Market data provider |
|
||||
| `BROKER_MODE` | `paper` | Broker mode: `paper` or `live` |
|
||||
@@ -193,8 +253,59 @@ All application services support additional environment variables loaded via `se
|
||||
| `TRADING_RISK_TIER` | `moderate` | Risk tier: `conservative`, `moderate`, `aggressive` |
|
||||
| `TRADING_POLLING_INTERVAL_SECONDS` | `60` | Recommendation polling interval |
|
||||
| `TRADING_MAX_OPEN_POSITIONS` | `10` | Maximum concurrent open positions |
|
||||
| `TRADING_RESERVE_SIPHON_PCT` | `0.20` | Percentage of profits siphoned to reserve pool |
|
||||
| `TRADING_STOP_LOSS_CHECK_INTERVAL_SECONDS` | `300` | Stop-loss check interval |
|
||||
| `TRADING_FAST_STOP_LOSS_INTERVAL_SECONDS` | `60` | Fast stop-loss check interval |
|
||||
| `TRADING_GRADUAL_ENTRY_TRANCHES` | `3` | Number of tranches for gradual entry |
|
||||
| `TRADING_GRADUAL_ENTRY_THRESHOLD_DOLLARS` | `30.0` | Dollar threshold for gradual entry |
|
||||
| `TRADING_ABSOLUTE_POSITION_CAP` | `50.0` | Maximum position size (dollars) |
|
||||
| `TRADING_ACTIVE_POOL_MINIMUM` | `100.0` | Minimum active pool balance |
|
||||
| `TRADING_EMERGENCY_DRAWDOWN_THRESHOLD_PCT` | `0.40` | Emergency drawdown threshold |
|
||||
| `TRADING_RESERVE_HIGH_WATER_PCT` | `0.30` | Reserve high-water mark percentage |
|
||||
| `TRADING_MICRO_TRADING_ENABLED` | `false` | Enable micro-trading mode |
|
||||
| `TRADING_MICRO_TRADING_INTERVAL_SECONDS` | `300` | Micro-trading polling interval |
|
||||
| `TRADING_MICRO_TRADING_ALLOCATION_CAP_PCT` | `0.03` | Micro-trading allocation cap |
|
||||
| `TRADING_MICRO_TRADING_MAX_DAILY` | `10` | Max micro-trades per day |
|
||||
| `TRADING_MICRO_TRADING_MAX_HOLD_MINUTES` | `120` | Max micro-trade hold time |
|
||||
| `TRADING_SNS_TOPIC_ARN` | (empty) | AWS SNS topic ARN for notifications |
|
||||
| `TRADING_SNS_PHONE_NUMBER` | (empty) | Phone number for SNS notifications |
|
||||
| `TRADING_GMAIL_SENDER` | (empty) | Gmail sender address for notifications |
|
||||
| `TRADING_GMAIL_RECIPIENT` | (empty) | Gmail recipient address for notifications |
|
||||
| `MACRO_ENABLED` | `true` | Enable macro signal layer |
|
||||
| `MACRO_SIGNAL_WEIGHT` | `0.3` | Relative weight of macro vs company signals |
|
||||
| `MACRO_CONFIDENCE_THRESHOLD` | `0.4` | Minimum confidence for macro event inclusion |
|
||||
| `MACRO_SHORT_TERM_STALENESS_HOURS` | `48` | Hours before short-term events get accelerated decay |
|
||||
| `PROJECTION_CONFIDENCE_THRESHOLD` | `0.3` | Minimum confidence for projections to influence recommendations |
|
||||
| `COMPETITIVE_ENABLED` | `true` | Enable competitive signal layer |
|
||||
| `COMPETITIVE_SIGNAL_WEIGHT` | `0.2` | Relative weight of competitive signals |
|
||||
| `COMPETITIVE_PATTERN_CONFIDENCE_THRESHOLD` | `0.3` | Minimum confidence for pattern inclusion |
|
||||
| `COMPETITIVE_PROPAGATION_STRENGTH_THRESHOLD` | `0.2` | Minimum strength for signal propagation |
|
||||
| `COMPETITIVE_ROUTINE_LOOKBACK_DAYS` | `180` | Lookback window for routine patterns |
|
||||
| `COMPETITIVE_MAJOR_DECISION_LOOKBACK_DAYS` | `365` | Lookback window for major decisions |
|
||||
| `COMPETITIVE_MIN_PATTERN_SAMPLES` | `3` | Minimum samples for pattern matching |
|
||||
| `COMPETITIVE_MAJOR_DECISION_WEIGHT_MULTIPLIER` | `1.3` | Weight multiplier for major decision patterns |
|
||||
| `COMPETITIVE_STALENESS_WINDOW_DAYS` | `180` | Window for staleness decay on competitive signals |
|
||||
| `COMPETITIVE_STALENESS_RECENT_DAYS` | `90` | Days within which signals are considered recent |
|
||||
| `COMPETITIVE_STALENESS_DECAY_PENALTY` | `0.5` | Decay penalty for stale competitive signals |
|
||||
| `COMPETITIVE_PROPAGATION_FAILURE_THRESHOLD` | `5` | Consecutive propagation failures before operator alert |
|
||||
| `ALERT_SOURCE_FAILURE_THRESHOLD` | `3` | Consecutive source failures before alert fires |
|
||||
| `ALERT_SOURCE_FAILURE_WINDOW_HOURS` | `6` | Lookback window for source failure alerting |
|
||||
| `ALERT_SCHEMA_FAILURE_RATE_THRESHOLD` | `0.3` | Extraction failure rate (30%) that triggers alert |
|
||||
| `ALERT_SCHEMA_FAILURE_WINDOW_HOURS` | `1` | Lookback window for schema failure spike |
|
||||
| `ALERT_LAKE_LAG_THRESHOLD_MINUTES` | `60` | Minutes since last lake publish before alert |
|
||||
| `ALERT_BROKER_ERROR_THRESHOLD` | `3` | Consecutive broker errors before alert |
|
||||
| `ALERT_BROKER_ERROR_WINDOW_HOURS` | `1` | Lookback window for broker error alerting |
|
||||
| `ALERT_CHECK_INTERVAL_SECONDS` | `120` | How often alerting rules are evaluated |
|
||||
| `RETENTION_RAW_MARKET_DAYS` | `90` | Retention period for raw market data (days) |
|
||||
| `RETENTION_RAW_NEWS_DAYS` | `180` | Retention period for raw news articles (days) |
|
||||
| `RETENTION_RAW_FILINGS_DAYS` | `365` | Retention period for raw SEC filings (days) |
|
||||
| `RETENTION_NORMALIZED_DAYS` | `180` | Retention period for normalized documents (days) |
|
||||
| `RETENTION_LLM_PROMPTS_DAYS` | `365` | Retention period for LLM prompt archives (days) |
|
||||
| `RETENTION_LLM_RESULTS_DAYS` | `365` | Retention period for LLM extraction results (days) |
|
||||
| `RETENTION_LAKEHOUSE_DAYS` | `730` | Retention period for lakehouse Parquet files (days) |
|
||||
| `RETENTION_AUDIT_DAYS` | `730` | Retention period for audit trail artifacts (days) |
|
||||
| `RETENTION_CLEANUP_INTERVAL_HOURS` | `24` | How often the retention cleanup worker runs |
|
||||
| `RETENTION_BATCH_SIZE` | `1000` | Number of objects processed per cleanup batch |
|
||||
| `LOG_LEVEL` | `INFO` | Logging level |
|
||||
| `JSON_LOGS` | `true` | Enable structured JSON logging |
|
||||
| `DEPLOY_STAGE` | (empty) | Deployment stage prefix for bucket names |
|
||||
@@ -203,6 +314,107 @@ See `services/shared/config.py` for the complete list of all supported environme
|
||||
|
||||
---
|
||||
|
||||
## LLM Provider Configuration
|
||||
|
||||
Stonks Oracle supports two LLM backends: **Ollama** (local, self-hosted) and **vLLM** (high-performance inference server). The active provider is configured per-agent in the `ai_agents` database table, but the connection details come from environment variables.
|
||||
|
||||
### Option A: Bundled Ollama (default)
|
||||
|
||||
The `docker-compose.yml` includes an Ollama container with GPU passthrough via the NVIDIA Container Toolkit. On first start, pull a model:
|
||||
|
||||
```bash
|
||||
docker compose exec ollama ollama pull qwen3.5:9b-fast
|
||||
```
|
||||
|
||||
No additional configuration needed — services connect to `http://ollama:11434` by default.
|
||||
|
||||
The Ollama container requests all available NVIDIA GPUs via the `deploy.resources.reservations.devices` configuration. If no GPU is available, Ollama falls back to CPU inference (significantly slower).
|
||||
|
||||
### Option B: External Ollama
|
||||
|
||||
If Ollama is already running on the host (e.g. with GPU access), create a `docker-compose.override.yml`:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
ollama:
|
||||
entrypoint: ["true"]
|
||||
restart: "no"
|
||||
ports: []
|
||||
extractor:
|
||||
depends_on:
|
||||
postgres:
|
||||
condition: service_healthy
|
||||
redis:
|
||||
condition: service_healthy
|
||||
environment:
|
||||
OLLAMA_BASE_URL: "http://host.docker.internal:11434"
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway"
|
||||
recommendation:
|
||||
environment:
|
||||
OLLAMA_BASE_URL: "http://host.docker.internal:11434"
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway"
|
||||
```
|
||||
|
||||
This disables the bundled Ollama container and routes services to the host's instance. Replace the port if your Ollama runs on a non-standard port. For a remote Ollama instance (not on localhost), replace `host.docker.internal` with the remote IP and remove the `extra_hosts` block.
|
||||
|
||||
### Option C: vLLM Server
|
||||
|
||||
For higher throughput or quantized models (e.g. `RedHatAI/Qwen3.6-35B-A3B-NVFP4`), point services at a vLLM server. Add to your `.env`:
|
||||
|
||||
```dotenv
|
||||
VLLM_BASE_URL=http://192.168.42.254:8000
|
||||
VLLM_MODEL=RedHatAI/Qwen3.6-35B-A3B-NVFP4
|
||||
VLLM_TIMEOUT=120
|
||||
VLLM_TEMPERATURE=0.7
|
||||
```
|
||||
|
||||
Then update the `ai_agents` table to use the vLLM provider:
|
||||
|
||||
```sql
|
||||
UPDATE ai_agents SET model_provider = 'vllm', model_name = 'RedHatAI/Qwen3.6-35B-A3B-NVFP4' WHERE active = true;
|
||||
```
|
||||
|
||||
Or use the API:
|
||||
|
||||
```bash
|
||||
curl -X PUT http://localhost:8004/api/admin/agents/document-extractor \
|
||||
-H 'Content-Type: application/json' \
|
||||
-d '{"model_provider": "vllm", "model_name": "RedHatAI/Qwen3.6-35B-A3B-NVFP4"}'
|
||||
```
|
||||
|
||||
### Option D: Mixed (Ollama + vLLM)
|
||||
|
||||
You can run different agents on different providers. For example, use vLLM for the high-volume extractor and Ollama for the thesis rewriter:
|
||||
|
||||
```sql
|
||||
UPDATE ai_agents SET model_provider = 'vllm', model_name = 'RedHatAI/Qwen3.6-35B-A3B-NVFP4' WHERE slug = 'document-extractor';
|
||||
UPDATE ai_agents SET model_provider = 'vllm', model_name = 'RedHatAI/Qwen3.6-35B-A3B-NVFP4' WHERE slug = 'event-classifier';
|
||||
UPDATE ai_agents SET model_provider = 'ollama', model_name = 'qwen3.5:9b-fast' WHERE slug = 'thesis-rewriter';
|
||||
```
|
||||
|
||||
Both `OLLAMA_BASE_URL` and `VLLM_BASE_URL` must be set in the environment for mixed mode.
|
||||
|
||||
### Automated Deployment
|
||||
|
||||
The `deploy-docker.sh` script handles LLM configuration automatically. It always uses the Docker Ollama container with GPU passthrough (NVIDIA Container Toolkit):
|
||||
|
||||
```bash
|
||||
# Deploy with defaults (Docker Ollama, GPU-accelerated)
|
||||
bash deploy-docker.sh
|
||||
|
||||
# Specify a custom model
|
||||
bash deploy-docker.sh --ollama-model qwen3.6
|
||||
|
||||
# Specify a different host and directory
|
||||
bash deploy-docker.sh --host user@myserver --dir /opt/stonks
|
||||
```
|
||||
|
||||
If an external Ollama URL is provided via `--ollama-url`, the script creates a `docker-compose.override.yml` that disables the bundled container and routes services to the external instance.
|
||||
|
||||
---
|
||||
|
||||
## Volume Mounts and Data Persistence
|
||||
|
||||
Docker Compose defines five named volumes for persistent data:
|
||||
@@ -299,6 +511,9 @@ docker compose ps query-api
|
||||
|
||||
# Inspect health check details for a container
|
||||
docker inspect --format='{{json .State.Health}}' stonks-oracle-query-api-1 | python -m json.tool
|
||||
|
||||
# Wait for all services to be healthy
|
||||
docker compose up -d --wait
|
||||
```
|
||||
|
||||
---
|
||||
@@ -309,17 +524,19 @@ docker inspect --format='{{json .State.Health}}' stonks-oracle-query-api-1 | pyt
|
||||
|
||||
Used by all application services except the scheduler. Accepts a `SERVICE_CMD` build argument that determines which service the container runs.
|
||||
|
||||
**Base image**: `python:3.12-slim`
|
||||
**Base image**: `python:3.12-slim` (via Harbor proxy cache in CI)
|
||||
|
||||
**Build arguments**:
|
||||
|
||||
| Argument | Default | Description |
|
||||
|----------|---------|-------------|
|
||||
| `SERVICE_CMD` | `python -m services.scheduler.app` | The command executed when the container starts |
|
||||
| `CACHE_BUST` | (none) | Optional cache-busting argument to force rebuild of source layers |
|
||||
|
||||
**What gets copied**:
|
||||
- `requirements.txt` → pip dependencies installed
|
||||
- `services/` → all service source code
|
||||
- `scripts/` → operational scripts
|
||||
- `tests/` → test files (available for in-container testing)
|
||||
- `conftest.py` → pytest configuration
|
||||
|
||||
@@ -357,7 +574,7 @@ A specialized variant of the generic Dockerfile used only by the `scheduler` ser
|
||||
|
||||
Extends the official Apache Superset image with additional database drivers.
|
||||
|
||||
**Base image**: `apache/superset:latest`
|
||||
**Base image**: `apache/superset:latest` (via Harbor proxy cache in CI)
|
||||
|
||||
**Additional packages**: `trino[sqlalchemy]`, `psycopg2-binary`, `redis`
|
||||
|
||||
@@ -376,7 +593,9 @@ Multi-stage build for the React dashboard.
|
||||
**Stage 2 — Serve** (base: `nginxinc/nginx-unprivileged:alpine`):
|
||||
- Serves the built static files on port 8080
|
||||
- Uses `frontend/nginx.conf` for SPA fallback and API reverse proxying
|
||||
- Proxies `/api/` → `query-api:8000`, `/registry/` → `symbol-registry:8000`, `/risk/` → `risk-engine:8000`, `/trading/` → `trading-engine:8000`
|
||||
- Proxies `/api/` → `query-api:8000`, `/registry/` → `symbol-registry:8000`, `/risk/` → `risk:8000`, `/trading/` → `trading-engine:8000`
|
||||
- SSE stream endpoint (`/api/ops/pipeline/stream`) has buffering disabled for real-time delivery
|
||||
- Static assets under `/assets/` are cached with 1-year expiry
|
||||
|
||||
### Building Custom Images
|
||||
|
||||
@@ -398,6 +617,9 @@ docker build -t my-dashboard \
|
||||
|
||||
# Rebuild all images
|
||||
docker compose build
|
||||
|
||||
# Rebuild without cache (force fresh build)
|
||||
docker compose build --no-cache
|
||||
```
|
||||
|
||||
---
|
||||
@@ -456,6 +678,9 @@ Services with `condition: service_healthy` wait until the dependency's health ch
|
||||
# Start all services in the background
|
||||
docker compose up -d
|
||||
|
||||
# Start all services and wait for health checks
|
||||
docker compose up -d --wait
|
||||
|
||||
# Start only infrastructure (useful for local development)
|
||||
docker compose up -d postgres redis minio minio-init ollama
|
||||
|
||||
@@ -534,6 +759,9 @@ docker compose exec query-api python -c "from services.shared.config import load
|
||||
|
||||
# Open a shell in a container
|
||||
docker compose exec postgres psql -U stonks -d stonks
|
||||
|
||||
# Seed the database
|
||||
docker compose exec scheduler python -m services.symbol_registry.seed
|
||||
```
|
||||
|
||||
### Full Reset
|
||||
@@ -575,11 +803,16 @@ The dashboard container runs nginx with reverse proxy rules that route API reque
|
||||
| Path | Proxied To | Service |
|
||||
|------|-----------|---------|
|
||||
| `/api/` | `http://query-api:8000` | Query API |
|
||||
| `/api/ops/pipeline/stream` | `http://query-api:8000` (SSE, no buffering) | Query API (real-time pipeline stream) |
|
||||
| `/registry/` | `http://symbol-registry:8000/` | Symbol Registry API |
|
||||
| `/risk/` | `http://risk-engine:8000/` | Risk Engine API |
|
||||
| `/risk/` | `http://risk:8000/` | Risk Engine (via network alias) |
|
||||
| `/trading/` | `http://trading-engine:8000/` | Trading Engine API |
|
||||
|
||||
All other paths serve the React SPA with `try_files` fallback to `index.html`.
|
||||
The `risk-engine` service has a network alias of `risk` in `docker-compose.yml` so the nginx upstream resolves correctly.
|
||||
|
||||
All other paths serve the React SPA with `try_files` fallback to `index.html`. Static assets under `/assets/` are served with 1-year cache headers.
|
||||
|
||||
Security headers applied: `X-Frame-Options: SAMEORIGIN`, `X-Content-Type-Options: nosniff`, `Referrer-Policy: strict-origin-when-cross-origin`.
|
||||
|
||||
---
|
||||
|
||||
@@ -610,10 +843,34 @@ docker compose up -d # Migrations re-applied on fresh init
|
||||
|
||||
### Ollama model not available
|
||||
|
||||
The extractor service needs an LLM model loaded in Ollama. Pull a model manually:
|
||||
The extractor service needs an LLM model loaded. Pull a model manually:
|
||||
|
||||
```bash
|
||||
docker compose exec ollama ollama pull qwen3.5:9b
|
||||
# If using bundled Ollama container:
|
||||
docker compose exec ollama ollama pull qwen3.5:9b-fast
|
||||
|
||||
# If using host Ollama:
|
||||
ollama pull qwen3.5:9b-fast
|
||||
|
||||
# If using vLLM, ensure the model is loaded on the vLLM server
|
||||
curl http://your-vllm-host:8000/v1/models
|
||||
```
|
||||
|
||||
### Ollama port conflict (address already in use)
|
||||
|
||||
If Ollama is already running on the host, the bundled container will fail to bind port 11434. Use the external Ollama configuration described in the "LLM Provider Configuration" section above, or use `deploy-docker.sh` which handles this automatically.
|
||||
|
||||
### GPU not detected by Ollama container
|
||||
|
||||
Ensure the NVIDIA Container Toolkit is installed and Docker is configured:
|
||||
|
||||
```bash
|
||||
# Verify GPU passthrough works
|
||||
docker run --rm --gpus all nvidia/cuda:12.8.0-base-ubuntu24.04 nvidia-smi
|
||||
|
||||
# If it fails, reconfigure Docker runtime
|
||||
sudo nvidia-ctk runtime configure --runtime=docker
|
||||
sudo systemctl restart docker
|
||||
```
|
||||
|
||||
### Port conflicts
|
||||
@@ -625,3 +882,15 @@ query-api:
|
||||
ports:
|
||||
- "9004:8000" # Changed from 8004 to 9004
|
||||
```
|
||||
|
||||
### Container runs out of memory
|
||||
|
||||
The full stack requires at least 16 GB RAM. If services are being OOM-killed:
|
||||
|
||||
```bash
|
||||
# Check which containers are using the most memory
|
||||
docker stats --no-stream
|
||||
|
||||
# Reduce memory usage by stopping non-essential services
|
||||
docker compose stop trino hive-metastore superset
|
||||
```
|
||||
@@ -0,0 +1,915 @@
|
||||
# Stonks Oracle — Mathematical Reference
|
||||
|
||||
Every equation, formula, threshold, and constant used in the signal processing, aggregation, recommendation, and trading pipeline. Organized by pipeline stage.
|
||||
|
||||
Code references are provided so each formula can be traced to its implementation.
|
||||
|
||||
---
|
||||
|
||||
## 1. Signal Scoring
|
||||
|
||||
**Source:** `services/aggregation/scoring.py`
|
||||
|
||||
### 1.1 Combined Signal Weight
|
||||
|
||||
Each document signal receives a composite weight:
|
||||
|
||||
```
|
||||
W_combined = G_conf × W_recency × W_credibility × (1 + B_novelty) × M_context
|
||||
```
|
||||
|
||||
| Component | Symbol | Formula | Range |
|
||||
|---|---|---|---|
|
||||
| Confidence gate | G_conf | 1 if extraction_confidence ≥ 0.2, else 0 | {0, 1} |
|
||||
| Recency decay | W_recency | 2^(−t_age / t_half) | [0.01, 1.0] |
|
||||
| Credibility | W_credibility | clamp(credibility, 0.1, 1.0)^α | [0.1, 1.0] |
|
||||
| Novelty bonus | B_novelty | novelty_score × 0.25 | [0, 0.25] |
|
||||
| Market context | M_context | 1 + boost_vol + boost_vol_surge | [1.0, 1.45] |
|
||||
|
||||
### 1.2 Recency Decay
|
||||
|
||||
```
|
||||
W_recency = max( 2^(−t_age / t_half), 0.01 )
|
||||
```
|
||||
|
||||
where `t_age` is document age in hours and half-lives by window are:
|
||||
|
||||
| Window | t_half (hours) |
|
||||
|---|---|
|
||||
| intraday | 2 |
|
||||
| 1d | 12 |
|
||||
| 7d | 72 |
|
||||
| 30d | 240 |
|
||||
| 90d | 720 |
|
||||
|
||||
### 1.3 Credibility Weight
|
||||
|
||||
```
|
||||
W_credibility = clamp(c_raw, 0.1, 1.0)^α where α = 1.0 (default)
|
||||
```
|
||||
|
||||
α > 1 penalizes low-credibility sources more aggressively; α < 1 flattens the curve.
|
||||
|
||||
### 1.4 Market Context Multiplier
|
||||
|
||||
```
|
||||
boost_vol = min( ln(1 + max(σ − 1.0, 0)) × 0.15, 0.30 )
|
||||
|
||||
boost_surge = 0.15 if ΔV% > 50%, else 0
|
||||
|
||||
M_context = 1.0 + boost_vol + boost_surge
|
||||
```
|
||||
|
||||
where σ is price volatility and ΔV% is volume change percentage.
|
||||
|
||||
### 1.5 Weighted Sentiment Average
|
||||
|
||||
```
|
||||
S_avg = Σ(W_combined_i × impact_i × sentiment_i) / Σ(W_combined_i × impact_i)
|
||||
```
|
||||
|
||||
- sentiment_i ∈ {+1.0 (positive), −1.0 (negative), 0.0 (neutral/mixed)}
|
||||
- impact_i ∈ [0, 1] from extraction
|
||||
- Returns 0.0 when denominator = 0
|
||||
|
||||
---
|
||||
|
||||
## 1B. Probabilistic Signal Scoring (Feature-Flagged)
|
||||
|
||||
**Source:** `services/aggregation/scoring.py`
|
||||
**Active when:** `probabilistic_scoring_enabled = true` in `risk_configs.config` JSONB
|
||||
|
||||
When the probabilistic pipeline is enabled, the combined weight formula changes:
|
||||
|
||||
### 1B.1 Combined Signal Weight (Probabilistic)
|
||||
|
||||
```
|
||||
W_combined = G_sigmoid × W_recency(adaptive) × W_credibility × (1 + B_novelty) × R_info × F_accuracy × M_regime
|
||||
```
|
||||
|
||||
| Component | Symbol | Formula | Range |
|
||||
|---|---|---|---|
|
||||
| Sigmoid gate | G_sigmoid | σ(k·(x − midpoint)) = 1/(1+e^(−5·(x−0.5))) | (0, 1) |
|
||||
| Adaptive recency | W_recency | 2^(−t_age / τ_adaptive) | [0.01, 1.0] |
|
||||
| Credibility | W_credibility | same as heuristic | [0.1, 1.0] |
|
||||
| Novelty bonus | B_novelty | same as heuristic | [0, 0.25] |
|
||||
| Information gain | R_info | 1 + λ·(−log₂ P(event_type)) | [1.0, 3.0] |
|
||||
| Source accuracy | F_accuracy | 0.5 + accuracy_ratio (if samples ≥ 10, else 1.0) | [0.5, 1.5] |
|
||||
| Regime multiplier | M_regime | 1 + 0.15·|z_r| + 0.10·|z_v| | [1.0, 2.5] |
|
||||
|
||||
### 1B.2 Sigmoid Confidence Gate
|
||||
|
||||
Replaces the binary 0/1 gate with a smooth transition:
|
||||
|
||||
```
|
||||
G_sigmoid = σ(k·(x − m)) = 1 / (1 + e^(−k·(x−m)))
|
||||
```
|
||||
|
||||
Default: k = 5.0, m = 0.5. At x=0.5 → 0.5; at x=0.2 → ~0.18; at x=0.8 → ~0.82.
|
||||
|
||||
### 1B.3 Information Gain (Surprise Weighting)
|
||||
|
||||
```
|
||||
R_info = min(1 + λ·(−log₂ P(event_type)), 3.0)
|
||||
```
|
||||
|
||||
| Event Type | P(event_type) | R_info (λ=0.3) |
|
||||
|---|---|---|
|
||||
| earnings | 0.25 | 1.60 |
|
||||
| dividend | 0.15 | 1.84 |
|
||||
| product_launch | 0.10 | 2.00 |
|
||||
| regulatory | 0.08 | 2.07 |
|
||||
| management_change | 0.06 | 2.19 |
|
||||
| legal | 0.05 | 2.29 |
|
||||
| restructuring | 0.04 | 2.39 |
|
||||
| m_and_a | 0.03 | 2.56 |
|
||||
| unknown | 0.10 (default) | 2.00 |
|
||||
|
||||
### 1B.4 Adaptive Recency Decay
|
||||
|
||||
```
|
||||
τ_adaptive = τ_base × (1 + β_impact) × (1 + β_surprise) × (1 + β_market)
|
||||
```
|
||||
|
||||
| Factor | Formula | Range |
|
||||
|---|---|---|
|
||||
| β_impact | impact_score × 1.0 | [0, 1.0] |
|
||||
| β_surprise | (R_info − 1) / 2 × 1.0 | [0, 1.0] |
|
||||
| β_market | (M_regime − 1) / 0.45 × 0.5 | [0, 0.5] |
|
||||
|
||||
Maximum adaptive half-life: 6× base (when all factors at max).
|
||||
Minimum: τ_base (adaptive decay is never faster than fixed).
|
||||
|
||||
### 1B.5 Regime Multiplier
|
||||
|
||||
```
|
||||
z_r = (r_t − μ_20) / σ_20 (return z-score)
|
||||
z_v = (ln(V_t) − μ_V) / σ_V (log-volume z-score)
|
||||
M_regime = clamp(1 + 0.15·|z_r| + 0.10·|z_v|, 1.0, 2.5)
|
||||
```
|
||||
|
||||
Defaults to 1.0 when market data unavailable or σ = 0.
|
||||
|
||||
### 1B.6 Source Accuracy Factor
|
||||
|
||||
```
|
||||
F_accuracy = 0.5 + clamp(accuracy_ratio, 0, 1) if sample_count ≥ 10
|
||||
F_accuracy = 1.0 if sample_count < 10
|
||||
```
|
||||
|
||||
Stored in `source_accuracy` table, updated asynchronously from realized 7-day price outcomes.
|
||||
|
||||
---
|
||||
|
||||
## 2. Trend Summary Assembly
|
||||
|
||||
**Source:** `services/aggregation/worker.py`
|
||||
|
||||
### 2.1 Trend Direction
|
||||
|
||||
| Condition | Direction |
|
||||
|---|---|
|
||||
| S_avg ≥ 0.15 | Bullish |
|
||||
| S_avg ≤ −0.15 | Bearish |
|
||||
| contradiction > 0.10 AND |S_avg| < 0.30 | Mixed |
|
||||
| otherwise | Neutral |
|
||||
|
||||
### 2.2 Trend Strength
|
||||
|
||||
```
|
||||
strength = min(|S_avg|, 1.0)
|
||||
```
|
||||
|
||||
### 2.3 Contradiction Score
|
||||
|
||||
**Source:** `services/aggregation/contradiction.py`
|
||||
|
||||
```
|
||||
contradiction = W_minority / (W_positive + W_negative)
|
||||
```
|
||||
|
||||
where:
|
||||
```
|
||||
W_positive = Σ(W_combined_i × impact_i) for signals with sentiment > 0
|
||||
W_negative = Σ(W_combined_i × impact_i) for signals with sentiment < 0
|
||||
W_minority = min(W_positive, W_negative)
|
||||
```
|
||||
|
||||
Range: [0, 1]. 0 = full agreement, 0.5 = equal-weight disagreement.
|
||||
|
||||
### 2.4 Trend Confidence
|
||||
|
||||
```
|
||||
confidence = clamp(0.3 × F_count + 0.3 × C_avg + 0.4 × A_agreement − P_contradiction, 0, 1)
|
||||
```
|
||||
|
||||
| Component | Formula |
|
||||
|---|---|
|
||||
| F_count (source count) | min(N_unique / 15, 0.8) |
|
||||
| C_avg (extraction confidence) | mean of extraction confidences |
|
||||
| A_agreement (signal agreement) | fraction_same_direction × min(1, log₂(N_unique + 1) / log₂(8)) |
|
||||
| P_contradiction | contradiction_score × 0.4 |
|
||||
|
||||
---
|
||||
|
||||
## 2B. Probabilistic Trend Assembly (Feature-Flagged)
|
||||
|
||||
**Source:** `services/aggregation/worker.py`, `services/aggregation/bayesian.py`
|
||||
**Active when:** `probabilistic_scoring_enabled = true`
|
||||
|
||||
### 2B.1 Bayesian Posterior Accumulation
|
||||
|
||||
```
|
||||
L_t = Σ(W_combined_i × sentiment_i) (log-likelihood)
|
||||
P_bull = σ(L_t) = 1 / (1 + e^(−L_t)) (bullish probability)
|
||||
α = 1 + W_bull (W_bull = Σ W_combined for positive signals)
|
||||
β = 1 + W_bear (W_bear = Σ W_combined for negative signals)
|
||||
C_bayesian = 1 − 4αβ / (α + β)² (Bayesian confidence)
|
||||
H = −P_bull·log₂(P_bull) − (1−P_bull)·log₂(1−P_bull) (Shannon entropy)
|
||||
```
|
||||
|
||||
Uninformative prior (no signals): P_bull=0.5, α=1, β=1, C=0, H=1.0.
|
||||
|
||||
### 2B.2 Entropy-Based Direction
|
||||
|
||||
| Condition | Direction |
|
||||
|---|---|
|
||||
| H > 0.9 | Mixed |
|
||||
| P_bull > 0.65 | Bullish |
|
||||
| P_bull < 0.35 | Bearish |
|
||||
| otherwise | Neutral |
|
||||
|
||||
### 2B.3 Bayesian Trend Confidence
|
||||
|
||||
```
|
||||
confidence = clamp(0.5 × C_bayesian + 0.25 × F_count + 0.25 × C_avg_credibility − P_contradiction, 0, 1)
|
||||
```
|
||||
|
||||
| Component | Formula |
|
||||
|---|---|
|
||||
| C_bayesian | 1 − 4αβ/(α+β)² from Beta posterior |
|
||||
| F_count | min(N_unique_sources / 15, 0.8) |
|
||||
| C_avg_credibility | mean credibility weight across active signals |
|
||||
| P_contradiction | contradiction_entropy × regime.contradiction_penalty_multiplier |
|
||||
|
||||
### 2B.4 Weighted Disagreement Entropy (Contradiction)
|
||||
|
||||
**Source:** `services/aggregation/contradiction.py`
|
||||
|
||||
```
|
||||
f_pos = W_positive / (W_positive + W_negative)
|
||||
f_neg = 1 − f_pos
|
||||
H_contradiction = −f_pos·log₂(f_pos) − f_neg·log₂(f_neg)
|
||||
contradiction_score = H_contradiction × min(1.0, (W_pos + W_neg) / W_threshold)
|
||||
```
|
||||
|
||||
W_threshold default = 5.0. Returns 0.0 when only one direction exists.
|
||||
|
||||
### 2B.5 Regime Detection
|
||||
|
||||
**Source:** `services/aggregation/regime.py`
|
||||
|
||||
```
|
||||
R = sign(EMA_20 − EMA_100) (trend indicator)
|
||||
V_r = σ_20 / σ_100 (volatility ratio)
|
||||
```
|
||||
|
||||
| Condition | Regime | Threshold | Contradiction Mult |
|
||||
|---|---|---|---|
|
||||
| V_r > 1.5 | Panic | ±0.10 | 0.4 |
|
||||
| R ≠ 0 AND V_r < 1.2 | Trend-following | ±0.15 | 0.4 |
|
||||
| R = 0 AND V_r < 1.0 | Mean-reversion | ±0.20 | 0.4 |
|
||||
| otherwise | Uncertainty | ±0.15 | 0.6 |
|
||||
|
||||
Falls back to Uncertainty when data < 100 days or σ = 0.
|
||||
|
||||
---
|
||||
|
||||
## 3. Macro Impact Scoring (Layer 2)
|
||||
|
||||
**Source:** `services/aggregation/interpolation.py`
|
||||
|
||||
### 3.1 Overlap Components
|
||||
|
||||
**Geographic overlap:**
|
||||
```
|
||||
O_geo = Σ revenue_pct_r for each event region r in company's revenue mix
|
||||
```
|
||||
Range: [0, 1]
|
||||
|
||||
**Supply chain overlap:**
|
||||
```
|
||||
O_supply = |event_regions ∩ supply_regions| / |supply_regions|
|
||||
```
|
||||
|
||||
**Commodity overlap:**
|
||||
```
|
||||
O_commodity = |event_commodities ∩ company_commodities| / |company_commodities|
|
||||
```
|
||||
|
||||
**Sector overlap:**
|
||||
```
|
||||
O_sector = 1.0 if company_sector ∈ event_affected_sectors, else 0.0
|
||||
```
|
||||
|
||||
### 3.2 Raw Macro Impact Score
|
||||
|
||||
```
|
||||
S_raw = W_severity × (0.35 × O_geo + 0.25 × O_supply + 0.25 × O_commodity + 0.15 × O_sector)
|
||||
```
|
||||
|
||||
Severity weights:
|
||||
|
||||
| Severity | W_severity |
|
||||
|---|---|
|
||||
| critical | 1.0 |
|
||||
| high | 0.75 |
|
||||
| moderate | 0.5 |
|
||||
| low | 0.25 |
|
||||
|
||||
### 3.3 Resilience Modifier
|
||||
|
||||
For international events, the raw score is adjusted by market position:
|
||||
|
||||
```
|
||||
S_final = clamp(S_raw × R_tier, 0, 1)
|
||||
```
|
||||
|
||||
| Market Position Tier | R_tier |
|
||||
|---|---|
|
||||
| Global leader | 0.70 |
|
||||
| Multinational | 0.85 |
|
||||
| Regional | 1.00 |
|
||||
| Domestic | 1.20 |
|
||||
|
||||
For domestic-only events, R_tier = 1.0 regardless of tier.
|
||||
|
||||
### 3B. Multiplicative Macro Exposure (Probabilistic)
|
||||
|
||||
**Active when:** `probabilistic_scoring_enabled = true`
|
||||
|
||||
```
|
||||
S_raw = W_severity × (1 − Π_k(1 − w_k × O_k))
|
||||
= W_severity × (1 − (1−0.35·O_geo)(1−0.25·O_supply)(1−0.25·O_commodity)(1−0.15·O_sector))
|
||||
```
|
||||
|
||||
Zero overlap → 0.0. Max overlap (all 1.0) → severity × 0.689.
|
||||
|
||||
### 3B.1 Conditional Macro Integration
|
||||
|
||||
When both company and macro signals exist:
|
||||
```
|
||||
modifier = clamp(1 + M_macro × sign_alignment, 0.5, 1.5)
|
||||
S_adjusted = S_company × modifier
|
||||
```
|
||||
|
||||
sign_alignment = +1 (agree), −1 (disagree), 0 (neutral/mixed).
|
||||
|
||||
When only macro signals exist: additive fallback with weight 0.3.
|
||||
When only company signals exist: modifier = 1.0.
|
||||
|
||||
### 3.4 Macro Impact Confidence
|
||||
|
||||
```
|
||||
confidence = min(event_confidence × min(O_total + 0.3, 1.0), 1.0)
|
||||
```
|
||||
|
||||
where O_total = O_geo + O_supply + O_commodity + O_sector.
|
||||
|
||||
### 3.5 Accelerated Staleness Decay
|
||||
|
||||
For short-term events older than 48 hours:
|
||||
|
||||
```
|
||||
decay_standard = e^(−0.693 × t_age_hours / t_half_hours) (t_half default = 168h)
|
||||
decay_accelerated = decay_standard × 0.5
|
||||
```
|
||||
|
||||
### 3.6 Macro Signal as WeightedSignal
|
||||
|
||||
When merged into the aggregation engine:
|
||||
|
||||
```
|
||||
impact_score_macro = macro_impact_score × W_macro (W_macro = 0.3 default)
|
||||
sentiment_value = +1 if positive, −1 if negative
|
||||
```
|
||||
|
||||
Recency decay uses the global event's publication time.
|
||||
|
||||
---
|
||||
|
||||
## 4. Competitive Signals (Layer 3)
|
||||
|
||||
### 4.1 Pattern Confidence
|
||||
|
||||
**Source:** `services/aggregation/pattern_matcher.py`
|
||||
|
||||
```
|
||||
confidence = F_sample × 0.4 + F_consistency × 0.4 + F_recency × 0.2
|
||||
```
|
||||
|
||||
| Factor | Formula |
|
||||
|---|---|
|
||||
| F_sample | min(N_samples / 20, 1.0) |
|
||||
| F_consistency | max(pct_bullish, pct_bearish) |
|
||||
| F_recency | 1.0 if age ≤ 7d; 0.7 if age ≤ 90d; 0.4 otherwise |
|
||||
|
||||
**Modifiers:**
|
||||
- Major corporate decision (m&a, earnings, legal): confidence × 1.3
|
||||
- Insufficient data (N_samples < min_pattern_samples): cap at 0.25
|
||||
- Stale data (age > staleness_window_days): confidence × staleness_decay_penalty
|
||||
|
||||
**Lookback windows:**
|
||||
- Routine signals: 180 days
|
||||
- Major corporate decisions: 365 days
|
||||
|
||||
### 4.2 Cross-Company Signal Strength
|
||||
|
||||
**Source:** `services/aggregation/signal_propagation.py`
|
||||
|
||||
```
|
||||
S_competitive = clamp(S_pattern_avg × R_relationship × C_pattern × I_source, 0, 1)
|
||||
```
|
||||
|
||||
| Component | Description |
|
||||
|---|---|
|
||||
| S_pattern_avg | Average historical outcome strength [0, 1] |
|
||||
| R_relationship | Relationship strength from competitor_relationships [0, 1] |
|
||||
| C_pattern | Pattern confidence from §4.1 |
|
||||
| I_source | Source document's impact_score [0, 1] |
|
||||
|
||||
**Threshold gate:** Skipped if R_relationship < propagation_strength_threshold (default 0.2).
|
||||
|
||||
### 4B. Graph-Distance Attenuation (Probabilistic)
|
||||
|
||||
**Active when:** `probabilistic_scoring_enabled = true`
|
||||
|
||||
```
|
||||
S_transfer = S_source × ρ_historical × e^(−d_network)
|
||||
```
|
||||
|
||||
| Component | Description |
|
||||
|---|---|
|
||||
| S_source | Source signal strength |
|
||||
| ρ_historical | 90-day rolling Pearson correlation (default 0.3 same-sector, 0.1 cross-sector) |
|
||||
| d_network | Shortest path in competitor graph (capped at 3) |
|
||||
|
||||
No propagation when d_network > 3 (e^(−3) ≈ 0.05).
|
||||
|
||||
### 4.3 Competitive Signal as WeightedSignal
|
||||
|
||||
```
|
||||
impact_score_competitive = S_competitive × W_competitive (W_competitive = 0.2 default)
|
||||
direction = majority historical outcome (bullish or bearish)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Trend Projection
|
||||
|
||||
**Source:** `services/aggregation/projection.py`
|
||||
|
||||
### 5.1 Trend Momentum
|
||||
|
||||
```
|
||||
momentum = S_current_signed − S_previous_signed
|
||||
```
|
||||
|
||||
where `S_signed = direction_sign × strength` (bullish = +1, bearish = −1, neutral = 0).
|
||||
|
||||
When no previous data exists:
|
||||
```
|
||||
momentum = direction_sign × strength × 0.5
|
||||
```
|
||||
|
||||
Range: [−1, 1]
|
||||
|
||||
### 5.2 Macro Decay Projection
|
||||
|
||||
For each active macro event projected forward by `H` days:
|
||||
|
||||
```
|
||||
F_future = 2^(−(t_current + H) / t_half)
|
||||
I_projected = macro_impact_score × F_future × W_severity
|
||||
```
|
||||
|
||||
Decay half-lives:
|
||||
|
||||
| Duration | t_half (days) |
|
||||
|---|---|
|
||||
| short_term | 1.0 |
|
||||
| medium_term | 7.0 |
|
||||
| long_term | 30.0 |
|
||||
|
||||
Aggregate direction: bullish if W_pos > 1.2 × W_neg; bearish if W_neg > 1.2 × W_pos; mixed if both > 0.
|
||||
|
||||
### 5.3 Projection Blending
|
||||
|
||||
```
|
||||
W_macro_blend = min(S_macro_projected × 0.4, 0.4)
|
||||
W_company = 1.0 − W_macro_blend
|
||||
|
||||
S_blended = W_company × S_momentum_projected + W_macro_blend × S_macro_signed
|
||||
```
|
||||
|
||||
**Catalyst boost:** `min(N_catalysts × 0.02, 0.1)` added to projected strength.
|
||||
|
||||
**Projected confidence:**
|
||||
```
|
||||
C_projected = C_base × 0.8 + min(S_macro × 0.15, 0.1)
|
||||
```
|
||||
|
||||
**Divergence detection:** Flagged when projected direction ≠ current trend direction.
|
||||
|
||||
### 5B. Exponentially Weighted Momentum (Probabilistic)
|
||||
|
||||
**Source:** `services/aggregation/projection.py`
|
||||
**Active when:** `probabilistic_scoring_enabled = true`
|
||||
|
||||
```
|
||||
M_t = Σ_{k=0}^{K-1} λ^k × ΔS_{t-k} (λ = 0.7, K ≤ 10)
|
||||
M_normalized = M_t / Σ_{k=0}^{K-1} λ^k (range: [−1, 1])
|
||||
M_adj = clamp(M_normalized / max(σ_20, 0.01), −2.0, 2.0)
|
||||
```
|
||||
|
||||
Falls back to heuristic momentum when < 2 historical cycles available.
|
||||
|
||||
---
|
||||
|
||||
## 6. Data Quality Suppression
|
||||
|
||||
**Source:** `services/recommendation/suppression.py`
|
||||
|
||||
### 6.1 Data Quality Score
|
||||
|
||||
```
|
||||
Q = 0.4 × Q_confidence + 0.3 × Q_freshness + 0.3 × Q_coverage
|
||||
```
|
||||
|
||||
| Component | Formula |
|
||||
|---|---|
|
||||
| Q_confidence | min(C_avg_extraction / 0.8, 1.0) |
|
||||
| Q_freshness | max(0, 1 − t_newest_hours / 168) |
|
||||
| Q_coverage | (N_valid / N_total) × min(N_valid / 10, 1.0) |
|
||||
|
||||
**Suppression triggers** (any one → informational only):
|
||||
|
||||
| Check | Threshold |
|
||||
|---|---|
|
||||
| Avg extraction confidence | < 0.40 |
|
||||
| Evidence staleness | > 168 hours (7 days) |
|
||||
| Source type diversity | < 1 distinct type |
|
||||
| Extraction failure rate | > 50% |
|
||||
| Valid document count | < 2 |
|
||||
| Data quality score | < 0.30 |
|
||||
|
||||
### 6.2 Safety Suppression
|
||||
|
||||
- **Macro-only:** If trend driven solely by macro signals with zero company evidence → forced informational
|
||||
- **Pattern-only:** If trend driven solely by pattern/competitive signals with no company or macro support → forced informational
|
||||
|
||||
---
|
||||
|
||||
## 7. Recommendation Eligibility
|
||||
|
||||
**Source:** `services/recommendation/eligibility.py`
|
||||
|
||||
### 7.1 Gate Checks (all must pass)
|
||||
|
||||
| Check | Threshold |
|
||||
|---|---|
|
||||
| Confidence | ≥ 0.35 |
|
||||
| Trend strength | ≥ 0.10 |
|
||||
| Contradiction score | ≤ 0.60 |
|
||||
| Evidence count | ≥ 2 |
|
||||
| Direction | ≠ neutral |
|
||||
|
||||
### 7.2 Action Mapping
|
||||
|
||||
| Condition | Action |
|
||||
|---|---|
|
||||
| Bullish AND strength ≥ 0.25 | BUY |
|
||||
| Bearish AND strength ≥ 0.25 | SELL |
|
||||
| Directional AND confidence ≥ 0.50 | HOLD |
|
||||
| Mixed or weak | WATCH |
|
||||
|
||||
### 7.3 Mode Escalation
|
||||
|
||||
| Mode | Requirements |
|
||||
|---|---|
|
||||
| live_eligible | confidence ≥ 0.70, contradiction ≤ 0.25, evidence ≥ 5 |
|
||||
| paper_eligible | confidence ≥ 0.50 |
|
||||
| informational | everything else (WATCH/HOLD always informational) |
|
||||
|
||||
### 7B. Expected Value Gate (Probabilistic)
|
||||
|
||||
**Active when:** `probabilistic_scoring_enabled = true`
|
||||
|
||||
```
|
||||
R_up = strength × σ_20 × √(horizon_days)
|
||||
R_down = (1 − strength) × σ_20 × √(horizon_days)
|
||||
EV = P_bull × R_up − (1 − P_bull) × R_down
|
||||
```
|
||||
|
||||
| Horizon window | horizon_days |
|
||||
|---|---|
|
||||
| intraday / 1d | 1 |
|
||||
| 7d | 7 |
|
||||
| 30d | 30 |
|
||||
| 90d | 90 |
|
||||
|
||||
- EV > 0.005 (0.5% expected return): recommendation proceeds through existing gates
|
||||
- EV ≤ 0.005: forced to informational mode regardless of confidence/strength
|
||||
- All existing eligibility gates (§7.1) remain as additional requirements
|
||||
|
||||
### 7.4 Position Sizing
|
||||
|
||||
```
|
||||
portfolio_pct = base + C_factor × S_factor × range × P_contradiction × P_evidence
|
||||
```
|
||||
|
||||
| Component | Formula | Default |
|
||||
|---|---|---|
|
||||
| base | base_portfolio_pct | 0.01 (1%) |
|
||||
| range | max_portfolio_pct − base_portfolio_pct | 0.09 (9%) |
|
||||
| C_factor | confidence_sizing_weight × confidence | 0.8 × confidence |
|
||||
| S_factor | 0.5 + 0.5 × trend_strength | [0.5, 1.0] |
|
||||
| P_contradiction | 1 − (contradiction_penalty × contradiction_score) | penalty = 0.5 |
|
||||
| P_evidence | 0.50 if evidence < 3; 0.75 if evidence < 5; 1.0 otherwise | |
|
||||
|
||||
Clamped to [base × 0.5, max_portfolio_pct].
|
||||
|
||||
**Max loss percentage** uses the same structure with base = 0.003 (0.3%) and max = 0.02 (2%).
|
||||
|
||||
---
|
||||
|
||||
## 8. Trading Engine — Position Sizing
|
||||
|
||||
**Source:** `services/trading/position_sizer.py`
|
||||
|
||||
### 8.1 Base Allocation
|
||||
|
||||
```
|
||||
raw_pct = (max_position_pct × 0.5) × (confidence / min_confidence) × multiplier
|
||||
clamped_pct = min(raw_pct, max_position_pct)
|
||||
dollar_amount = min(active_pool × clamped_pct, absolute_position_cap)
|
||||
```
|
||||
|
||||
### 8.2 Correlation Reduction
|
||||
|
||||
```
|
||||
ρ_avg = Σ(ρ_i × w_i) / Σ(w_i) for existing positions
|
||||
```
|
||||
|
||||
| ρ_avg | Action |
|
||||
|---|---|
|
||||
| > 0.8 | Reject order |
|
||||
| 0.5 < ρ_avg ≤ 0.8 | Reduce: factor = 1 − (ρ_avg − 0.5) / 0.3 |
|
||||
| ≤ 0.5 | No reduction |
|
||||
|
||||
### 8.3 Sector Exposure Reduction
|
||||
|
||||
```
|
||||
available = max(max_sector_pct × active_pool − current_sector_exposure, 0)
|
||||
dollar_amount = min(dollar_amount, available)
|
||||
```
|
||||
|
||||
### 8.4 Diversification Bonus
|
||||
|
||||
If < 3 sectors held AND entering a new sector: dollar_amount × 1.2 (capped at max_position_pct).
|
||||
|
||||
### 8.5 Earnings Proximity
|
||||
|
||||
| Days to earnings | Action |
|
||||
|---|---|
|
||||
| ≤ 1 | Reject |
|
||||
| 1–3 | 50% reduction |
|
||||
| > 3 | No adjustment |
|
||||
|
||||
### 8.6 Portfolio Heat Check
|
||||
|
||||
```
|
||||
heat_new = dollar_amount × atr_multiplier × 0.02
|
||||
heat_max = max_portfolio_heat × active_pool
|
||||
|
||||
Reject if: heat_current + heat_new > heat_max
|
||||
```
|
||||
|
||||
### 8.7 Share Rounding
|
||||
|
||||
```
|
||||
shares = floor(dollar_amount / current_price)
|
||||
final_dollar = shares × current_price
|
||||
```
|
||||
|
||||
Reject if shares = 0.
|
||||
|
||||
---
|
||||
|
||||
## 9. Stop-Loss and Take-Profit
|
||||
|
||||
**Source:** `services/trading/stop_loss_manager.py`
|
||||
|
||||
### 9.1 Initial Levels
|
||||
|
||||
```
|
||||
stop_distance = ATR × M_atr
|
||||
stop_loss = entry_price − stop_distance
|
||||
take_profit = entry_price + stop_distance × R_reward_risk
|
||||
```
|
||||
|
||||
| Trade type | M_atr | R_reward_risk |
|
||||
|---|---|---|
|
||||
| Standard | risk_tier.stop_loss_atr_multiplier | risk_tier.reward_risk_ratio |
|
||||
| Micro-trade | 1.0 | 1.5 |
|
||||
|
||||
### 9.2 Dynamic Tightening
|
||||
|
||||
| Condition | Effective multiplier |
|
||||
|---|---|
|
||||
| High-severity macro event | base × 0.5 |
|
||||
| Earnings within 3 days | base × 0.7 |
|
||||
| Portfolio heat > 80% of max | base × 0.7 |
|
||||
| Normal | base |
|
||||
|
||||
### 9.3 Trailing Stop Activation
|
||||
|
||||
Activates when:
|
||||
```
|
||||
favorable_move = current_price − entry_price > 0.5 × (take_profit − entry_price)
|
||||
```
|
||||
|
||||
Once active, stop-loss floor = entry_price (breakeven).
|
||||
|
||||
---
|
||||
|
||||
## 10. Risk Management
|
||||
|
||||
### 10.1 Position Limits
|
||||
|
||||
**Source:** `services/risk/engine.py`
|
||||
|
||||
| Limit | Default | Formula |
|
||||
|---|---|---|
|
||||
| Max position % | 5% | position_value / portfolio_value ≤ 0.05 |
|
||||
| Max position value | $10,000 | existing + new ≤ $10,000 |
|
||||
| Max shares/order | 1,000 | quantity ≤ 1,000 |
|
||||
| Max sector % | 25% | sector_value / portfolio_value ≤ 0.25 |
|
||||
| Max daily loss % | 2% | |daily_pnl| / portfolio_value ≤ 0.02 |
|
||||
| Max daily loss $ | $1,000 | |daily_pnl| ≤ $1,000 |
|
||||
| Max daily trades | 20 | trade_count < 20 |
|
||||
|
||||
### 10.2 Order Clamping
|
||||
|
||||
**Source:** `services/risk/engine.py` — `clamp_order_to_position_limits()`
|
||||
|
||||
When a buy order exceeds position limits, instead of rejecting:
|
||||
|
||||
```
|
||||
max_allowed_value = min(
|
||||
max_position_value − existing_value,
|
||||
max_position_pct × portfolio_value − existing_value
|
||||
)
|
||||
clamped_shares = min( floor(max_allowed_value / price_per_share), max_shares_per_order )
|
||||
```
|
||||
|
||||
### 10.3 News Shock Lockout
|
||||
|
||||
Trigger: impact_score ≥ 0.80 for catalyst ∈ {earnings, legal, m_and_a}
|
||||
Duration: 60 minutes (configurable)
|
||||
|
||||
### 10.4 Symbol Cooldown
|
||||
|
||||
Duration: 15 minutes between trades on same symbol.
|
||||
Max concurrent positions per symbol: 1.
|
||||
|
||||
---
|
||||
|
||||
## 11. Circuit Breaker
|
||||
|
||||
**Source:** `services/trading/circuit_breaker.py`
|
||||
|
||||
| Trigger | Condition | Cooldown |
|
||||
|---|---|---|
|
||||
| Daily loss | |daily_pnl| / portfolio_value > 0.05 | 2 hours |
|
||||
| Single position | position_loss_pct > 0.15 | 48 hours |
|
||||
| Volatility | ≥ 3 stop-losses within 30-minute window | 2 hours |
|
||||
|
||||
---
|
||||
|
||||
## 12. Risk Tier Auto-Adjustment
|
||||
|
||||
**Source:** `services/trading/risk_tier_controller.py`
|
||||
|
||||
Tiers: conservative → moderate → aggressive
|
||||
|
||||
**Downgrade** (any one triggers, drops one level):
|
||||
- 30-day win rate < 40%
|
||||
- Current drawdown > 15%
|
||||
|
||||
**Upgrade** (all must be true, raises one level):
|
||||
- 30-day win rate > 55%
|
||||
- Reserve pool > 20% of portfolio
|
||||
- Current drawdown < 5%
|
||||
|
||||
---
|
||||
|
||||
## 13. Portfolio Rebalancing
|
||||
|
||||
**Source:** `services/trading/rebalancer.py`
|
||||
|
||||
### 13.1 Single-Stock Rebalancing
|
||||
|
||||
```
|
||||
excess = market_value − max_position_pct × active_pool
|
||||
sell_qty = min( floor(excess / current_price), position_quantity )
|
||||
```
|
||||
|
||||
### 13.2 Sector Rebalancing
|
||||
|
||||
```
|
||||
sector_excess = Σ(market_value_i) − max_sector_pct × active_pool
|
||||
```
|
||||
|
||||
Sell from lowest-confidence positions first until excess is covered.
|
||||
|
||||
### 13.3 Max Positions Enforcement
|
||||
|
||||
```
|
||||
excess_count = N_positions − max_positions
|
||||
```
|
||||
|
||||
Sell entire lowest-confidence positions until count is within limit.
|
||||
|
||||
---
|
||||
|
||||
## Constants Summary
|
||||
|
||||
| Constant | Value | Location |
|
||||
|---|---|---|
|
||||
| Confidence gate floor | 0.20 | scoring.py |
|
||||
| Min recency weight | 0.01 | scoring.py |
|
||||
| Credibility floor/ceiling | 0.10 / 1.0 | scoring.py |
|
||||
| Novelty bonus max | 0.25 (25%) | scoring.py |
|
||||
| Volatility boost threshold | 1.0 price units | scoring.py |
|
||||
| Volatility boost max | 0.30 (30%) | scoring.py |
|
||||
| Volume surge threshold | 50% | scoring.py |
|
||||
| Volume surge boost | 0.15 (15%) | scoring.py |
|
||||
| Bullish/bearish threshold | ±0.15 | worker.py |
|
||||
| Mixed threshold | contradiction > 0.10, |S| < 0.30 | worker.py |
|
||||
| Macro signal weight | 0.30 | config.py |
|
||||
| Competitive signal weight | 0.20 | config.py |
|
||||
| Macro confidence threshold | 0.40 | interpolation.py |
|
||||
| Staleness accelerated decay | 0.50× | interpolation.py |
|
||||
| Short-term staleness hours | 48 | interpolation.py |
|
||||
| Pattern min samples | configurable | pattern_matcher.py |
|
||||
| Major decision weight multiplier | 1.3× | pattern_matcher.py |
|
||||
| Routine lookback | 180 days | pattern_matcher.py |
|
||||
| Major decision lookback | 365 days | pattern_matcher.py |
|
||||
| Propagation strength threshold | 0.20 | signal_propagation.py |
|
||||
| Data quality min score | 0.30 | suppression.py |
|
||||
| Evidence staleness max | 168 hours (7 days) | suppression.py |
|
||||
| Recommendation min confidence | 0.35 | eligibility.py |
|
||||
| Recommendation min strength | 0.10 | eligibility.py |
|
||||
| Action strength threshold | 0.25 | eligibility.py |
|
||||
| Live confidence threshold | 0.70 | eligibility.py |
|
||||
| Paper confidence threshold | 0.50 | eligibility.py |
|
||||
| Base portfolio allocation | 1% | eligibility.py |
|
||||
| Max portfolio allocation | 10% | eligibility.py |
|
||||
| Circuit breaker daily loss | 5% | circuit_breaker.py |
|
||||
| Circuit breaker single position | 15% | circuit_breaker.py |
|
||||
| Stop-loss cluster threshold | 3 hits / 30 min | circuit_breaker.py |
|
||||
| Tier downgrade win rate | < 40% | risk_tier_controller.py |
|
||||
| Tier upgrade win rate | > 55% | risk_tier_controller.py |
|
||||
| Tier upgrade max drawdown | < 5% | risk_tier_controller.py |
|
||||
| Tier upgrade min reserve | > 20% | risk_tier_controller.py |
|
||||
| **Probabilistic pipeline** | | |
|
||||
| Sigmoid steepness (k) | 5.0 | scoring.py |
|
||||
| Sigmoid midpoint (m) | 0.5 | scoring.py |
|
||||
| Info gain lambda (λ) | 0.3 | scoring.py |
|
||||
| Info gain max clamp | 3.0 | scoring.py |
|
||||
| Default base rate | 0.10 | scoring.py |
|
||||
| Adaptive decay impact scale | 1.0 | scoring.py |
|
||||
| Adaptive decay surprise scale | 1.0 | scoring.py |
|
||||
| Adaptive decay market scale | 0.5 | scoring.py |
|
||||
| Regime return weight | 0.15 | scoring.py |
|
||||
| Regime volume weight | 0.10 | scoring.py |
|
||||
| Regime multiplier max | 2.5 | scoring.py |
|
||||
| Source accuracy min samples | 10 | source_accuracy.py |
|
||||
| Contradiction W_threshold | 5.0 | contradiction.py |
|
||||
| EMA short period | 20 days | regime.py |
|
||||
| EMA long period | 100 days | regime.py |
|
||||
| Panic volatility ratio | > 1.5 | regime.py |
|
||||
| Trend-following vol ratio | < 1.2 | regime.py |
|
||||
| Mean-reversion vol ratio | < 1.0 | regime.py |
|
||||
| Panic threshold | ±0.10 | regime.py |
|
||||
| Mean-reversion threshold | ±0.20 | regime.py |
|
||||
| Uncertainty contradiction mult | 0.6 | regime.py |
|
||||
| EW momentum decay (λ) | 0.7 | projection.py |
|
||||
| EW momentum max lags (K) | 10 | projection.py |
|
||||
| Volatility floor (σ min) | 0.01 | projection.py |
|
||||
| Momentum clamp | ±2.0 | projection.py |
|
||||
| EV threshold | 0.005 (0.5%) | eligibility.py |
|
||||
| Graph distance max | 3 | signal_propagation.py |
|
||||
| Default correlation (same-sector) | 0.3 | signal_propagation.py |
|
||||
| Default correlation (cross-sector) | 0.1 | signal_propagation.py |
|
||||
+49
-31
@@ -94,7 +94,7 @@ Each key under `services` defines a Kubernetes Deployment. The deployments templ
|
||||
| `image` | string | yes | Image name appended to `image.registry`. Also used as the Deployment name and pod label (`app: <image>`). |
|
||||
| `command` | string | no | Shell command passed as `["sh", "-c", "<command>"]`. Omit for images with a built-in entrypoint (e.g., dashboard/nginx). |
|
||||
| `tier` | string | yes | Service tier label (`stonks-oracle/tier`). One of: `api`, `frontend`, `processing`, `trading`, `orchestration`, `analytics`, `ingestion`. |
|
||||
| `port` | int | no | Container port. When set, a Kubernetes Service is created mapping `port → port`. |
|
||||
| `port` | int | no | Container port. When set, a Kubernetes Service is created mapping `port -> port`. |
|
||||
| `pipeline` | bool | no | If `true`, replicas are set to 0 when `pipelineEnabled` is `false`. |
|
||||
| `secrets` | list(string) | no | List of Secret names to mount via `envFrom.secretRef`. |
|
||||
| `resources` | object | yes | Kubernetes resource requests and limits (`cpu`, `memory`). |
|
||||
@@ -118,9 +118,10 @@ Each key under `services` defines a Kubernetes Deployment. The deployments templ
|
||||
| `resources.limits` | cpu: 200m, memory: 128Mi |
|
||||
| `probes` | — |
|
||||
|
||||
The scheduler deployment has two init containers (not configurable via values):
|
||||
The scheduler deployment has three init containers (not configurable via values):
|
||||
1. **run-migrations** — applies all SQL files from `infra/migrations/*.sql` in sorted order.
|
||||
2. **seed-if-empty** — runs `python -m services.symbol_registry.seed` if the `companies` table is empty.
|
||||
3. **backfill-market-data** — runs `scripts/backfill_market_data.py` if available (skips gracefully if not).
|
||||
|
||||
#### symbolRegistry
|
||||
|
||||
@@ -141,7 +142,7 @@ The scheduler deployment has two init containers (not configurable via values):
|
||||
|
||||
| Field | Value |
|
||||
|-------|-------|
|
||||
| `replicas` | `2` |
|
||||
| `replicas` | `1` |
|
||||
| `pipeline` | `true` |
|
||||
| `image` | `ingestion` |
|
||||
| `command` | `python -m services.ingestion.worker` |
|
||||
@@ -274,7 +275,7 @@ Single replica is recommended — the extractor is bottlenecked by the shared Ol
|
||||
| `command` | `uvicorn services.api.app:app --host 0.0.0.0 --port 8000` |
|
||||
| `tier` | `api` |
|
||||
| `port` | `8000` |
|
||||
| `secrets` | `stonks-core-secrets` |
|
||||
| `secrets` | `stonks-core-secrets`, `stonks-market-secrets` |
|
||||
| `resources.requests` | cpu: 100m, memory: 128Mi |
|
||||
| `resources.limits` | cpu: 500m, memory: 256Mi |
|
||||
| `probes.readiness` | path: `/docs`, port: 8000, initialDelay: 5s, period: 10s |
|
||||
@@ -323,7 +324,7 @@ All keys under `config` are rendered into a Kubernetes ConfigMap named `stonks-c
|
||||
|
||||
| Key | Type | Default | Description |
|
||||
|-----|------|---------|-------------|
|
||||
| `config.OLLAMA_BASE_URL` | string | `""` (empty) | Ollama API base URL. Set to the cluster-internal or external Ollama endpoint. |
|
||||
| `config.OLLAMA_BASE_URL` | string | `http://10.1.1.12:2701` | Ollama API base URL. Points to the external Ollama endpoint by default. |
|
||||
| `config.OLLAMA_MODEL` | string | `qwen3.5:9b-fast` | Default LLM model for extraction and classification agents. |
|
||||
| `config.OLLAMA_TIMEOUT` | string | `240` | Request timeout in seconds for Ollama API calls. |
|
||||
| `config.OLLAMA_MAX_RETRIES` | string | `2` | Maximum retry attempts for failed Ollama requests. |
|
||||
@@ -331,6 +332,17 @@ All keys under `config` are rendered into a Kubernetes ConfigMap named `stonks-c
|
||||
| `config.OLLAMA_RETRY_MAX_DELAY` | string | `10.0` | Maximum delay cap in seconds for Ollama retry backoff. |
|
||||
| `config.OLLAMA_RETRY_BACKOFF_MULTIPLIER` | string | `2.0` | Multiplier for exponential backoff between Ollama retries. |
|
||||
|
||||
### vLLM
|
||||
|
||||
| Key | Type | Default | Description |
|
||||
|-----|------|---------|-------------|
|
||||
| `config.VLLM_BASE_URL` | string | `http://10.1.1.12:2701` | vLLM API base URL. Alternative LLM backend using OpenAI-compatible API. |
|
||||
| `config.VLLM_MODEL` | string | `qwen3.5:9b-fast` | vLLM model identifier. |
|
||||
| `config.VLLM_TIMEOUT` | string | `120` | Request timeout in seconds for vLLM API calls. |
|
||||
| `config.VLLM_MAX_RETRIES` | string | `2` | Maximum retry attempts for failed vLLM requests. |
|
||||
| `config.VLLM_TEMPERATURE` | string | `0.7` | Sampling temperature for vLLM generation (0.0-1.0). |
|
||||
| `config.VLLM_API_KEY` | string | `""` (empty) | API key for vLLM authentication. Leave empty if not required. |
|
||||
|
||||
### Analytics / Trino
|
||||
|
||||
| Key | Type | Default | Description |
|
||||
@@ -347,7 +359,7 @@ All keys under `config` are rendered into a Kubernetes ConfigMap named `stonks-c
|
||||
|-----|------|---------|-------------|
|
||||
| `config.BROKER_MODE` | string | `paper` | Broker execution mode. `paper` for simulated trading, `live` for real orders. |
|
||||
| `config.BROKER_PROVIDER` | string | `""` (empty) | Broker provider name (e.g., `alpaca`). |
|
||||
| `config.MARKET_DATA_BASE_URL` | string | `""` (empty) | Market data API base URL (e.g., `https://api.polygon.io`). |
|
||||
| `config.MARKET_DATA_BASE_URL` | string | `https://api.polygon.io` | Market data API base URL. |
|
||||
| `config.MARKET_DATA_PROVIDER` | string | `polygon` | Market data provider identifier. |
|
||||
| `config.TRADING_ENABLED` | string | `true` | Master toggle for the trading engine. Set to `false` to disable order submission. |
|
||||
| `config.TRADING_RISK_TIER` | string | `moderate` | Default risk tier for position sizing. Options: `conservative`, `moderate`, `aggressive`. |
|
||||
@@ -376,6 +388,7 @@ All keys under `config` are rendered into a Kubernetes ConfigMap named `stonks-c
|
||||
| `config.LOG_LEVEL` | string | `INFO` | Python logging level. Options: `DEBUG`, `INFO`, `WARNING`, `ERROR`. |
|
||||
| `config.JSON_LOGS` | string | `true` | Emit structured JSON logs when `true`. |
|
||||
| `config.DEPLOY_STAGE` | string | `""` (empty) | Deployment stage identifier. Used to isolate Redis keys and MinIO buckets per stage (e.g., `beta`, `paper`). |
|
||||
| `config.TZ` | string | `America/Los_Angeles` | Container timezone. Affects log timestamps and any time-aware formatting. The frontend uses the browser's local timezone for display. |
|
||||
|
||||
### Alerting
|
||||
|
||||
@@ -383,7 +396,7 @@ All keys under `config` are rendered into a Kubernetes ConfigMap named `stonks-c
|
||||
|-----|------|---------|-------------|
|
||||
| `config.ALERT_SOURCE_FAILURE_THRESHOLD` | string | `3` | Number of consecutive source failures before firing an alert. |
|
||||
| `config.ALERT_SOURCE_FAILURE_WINDOW_HOURS` | string | `6` | Time window (hours) for evaluating source failure count. |
|
||||
| `config.ALERT_SCHEMA_FAILURE_RATE_THRESHOLD` | string | `0.3` | Schema validation failure rate (0.0–1.0) that triggers an alert. |
|
||||
| `config.ALERT_SCHEMA_FAILURE_RATE_THRESHOLD` | string | `0.3` | Schema validation failure rate (0.0-1.0) that triggers an alert. |
|
||||
| `config.ALERT_SCHEMA_FAILURE_WINDOW_HOURS` | string | `1` | Time window (hours) for evaluating schema failure rate. |
|
||||
| `config.ALERT_LAKE_LAG_THRESHOLD_MINUTES` | string | `60` | Minutes of lakehouse publish lag before alerting. |
|
||||
| `config.ALERT_BROKER_ERROR_THRESHOLD` | string | `3` | Number of broker errors before firing an alert. |
|
||||
@@ -394,7 +407,7 @@ All keys under `config` are rendered into a Kubernetes ConfigMap named `stonks-c
|
||||
|
||||
## `secrets` — Kubernetes Secrets
|
||||
|
||||
Secrets are rendered into five Kubernetes Secret objects. In the base `values.yaml`, all secret values default to empty strings. Inject real values at deploy time using `--set` flags or a values override file.
|
||||
Secrets are rendered into five Kubernetes Secret objects. Inject real values at deploy time using `--set` flags or a values override file. The base `values.yaml` contains placeholder values — override them for each environment.
|
||||
|
||||
### Secret Objects
|
||||
|
||||
@@ -402,32 +415,32 @@ Secrets are rendered into five Kubernetes Secret objects. In the base `values.ya
|
||||
|-------------|-----------|-------------|
|
||||
| `stonks-core-secrets` | `secrets.core` | All services |
|
||||
| `stonks-broker-secrets` | `secrets.broker` | ingestion, trading-engine, risk-engine, broker-adapter |
|
||||
| `stonks-market-secrets` | `secrets.market` | ingestion |
|
||||
| `stonks-market-secrets` | `secrets.market` | ingestion, query-api |
|
||||
| `stonks-gmail-secrets` | `secrets.gmail` | trading-engine |
|
||||
| `stonks-dashboard-secrets` | `secrets.dashboard` | superset |
|
||||
|
||||
### `secrets.core`
|
||||
|
||||
| Key | Type | Default | Description |
|
||||
|-----|------|---------|-------------|
|
||||
| `POSTGRES_PASSWORD` | string | `""` | PostgreSQL password. |
|
||||
| `MINIO_ACCESS_KEY` | string | `""` | MinIO access key (AWS-style). |
|
||||
| `MINIO_SECRET_KEY` | string | `""` | MinIO secret key. |
|
||||
| `REDIS_PASSWORD` | string | `""` | Redis authentication password. |
|
||||
| Key | Type | Description |
|
||||
|-----|------|-------------|
|
||||
| `POSTGRES_PASSWORD` | string | PostgreSQL password. |
|
||||
| `MINIO_ACCESS_KEY` | string | MinIO access key (AWS-style). |
|
||||
| `MINIO_SECRET_KEY` | string | MinIO secret key. |
|
||||
| `REDIS_PASSWORD` | string | Redis authentication password. |
|
||||
|
||||
### `secrets.broker`
|
||||
|
||||
| Key | Type | Default | Description |
|
||||
|-----|------|---------|-------------|
|
||||
| `BROKER_API_KEY` | string | `""` | Broker API key (e.g., Alpaca paper trading key). |
|
||||
| `BROKER_API_SECRET` | string | `""` | Broker API secret. |
|
||||
| `BROKER_BASE_URL` | string | `""` | Broker API base URL (e.g., `https://paper-api.alpaca.markets`). |
|
||||
| Key | Type | Description |
|
||||
|-----|------|-------------|
|
||||
| `BROKER_API_KEY` | string | Broker API key (e.g., Alpaca paper trading key). |
|
||||
| `BROKER_API_SECRET` | string | Broker API secret. |
|
||||
| `BROKER_BASE_URL` | string | Broker API base URL (e.g., `https://paper-api.alpaca.markets`). |
|
||||
|
||||
### `secrets.market`
|
||||
|
||||
| Key | Type | Default | Description |
|
||||
|-----|------|---------|-------------|
|
||||
| `MARKET_DATA_API_KEY` | string | `""` | Market data provider API key (e.g., Polygon.io). |
|
||||
| Key | Type | Description |
|
||||
|-----|------|-------------|
|
||||
| `MARKET_DATA_API_KEY` | string | Market data provider API key (e.g., Polygon.io). |
|
||||
|
||||
### `secrets.gmail`
|
||||
|
||||
@@ -439,10 +452,10 @@ Secrets are rendered into five Kubernetes Secret objects. In the base `values.ya
|
||||
|
||||
### `secrets.dashboard`
|
||||
|
||||
| Key | Type | Default | Description |
|
||||
|-----|------|---------|-------------|
|
||||
| `SUPERSET_SECRET_KEY` | string | `""` | Flask secret key for Superset session encryption. |
|
||||
| `SUPERSET_ADMIN_PASSWORD` | string | `""` | Superset admin user password. |
|
||||
| Key | Type | Description |
|
||||
|-----|------|-------------|
|
||||
| `SUPERSET_SECRET_KEY` | string | Flask secret key for Superset session encryption. |
|
||||
| `SUPERSET_ADMIN_PASSWORD` | string | Superset admin user password. |
|
||||
|
||||
### Injecting Secrets at Deploy Time
|
||||
|
||||
@@ -595,15 +608,20 @@ Key overrides:
|
||||
| `pipelineEnabled` | `true` | Services deployed (ArgoCD health checks), but pipeline defaults to OFF via `PIPELINE_DEFAULT_OFF`. |
|
||||
| `config.DEPLOY_STAGE` | `beta` | Isolates Redis keys (`stonks:beta:*`) and MinIO buckets (`beta-stonks-*`). |
|
||||
| `config.POSTGRES_DB` | `stonks_beta` | Separate database for beta data. |
|
||||
| `config.POSTGRES_USER` | `stonks_beta` | Separate database user for beta. |
|
||||
| `config.REDIS_DB` | `1` | Separate Redis DB index. |
|
||||
| `config.LOG_LEVEL` | `DEBUG` | Verbose logging for debugging. |
|
||||
| `config.TRADING_ENABLED` | `false` | Safety net — no order submission in beta. |
|
||||
| `config.PIPELINE_DEFAULT_OFF` | `true` | Scheduler won't enqueue jobs unless explicitly enabled. |
|
||||
| `config.TRADING_ENABLED` | `true` | Trading engine active but constrained by paper broker mode. |
|
||||
| `config.PIPELINE_DEFAULT_OFF` | `true` | Scheduler won't enqueue jobs unless explicitly enabled via the UI. |
|
||||
| `config.BROKER_MODE` | `paper` | Simulated order execution. |
|
||||
| `config.BROKER_PROVIDER` | `alpaca` | Alpaca paper trading API. |
|
||||
| `config.OLLAMA_MODEL` | `qwen3.6` | May use a different model version for testing. |
|
||||
| `trino.enabled` | `false` | Analytics stack disabled in beta. |
|
||||
| `hiveMetastore.enabled` | `false` | Analytics stack disabled in beta. |
|
||||
| `superset.enabled` | `false` | Analytics stack disabled in beta. |
|
||||
|
||||
Beta also configures vLLM settings (`VLLM_BASE_URL`, `VLLM_MODEL`, etc.) for testing alternative LLM backends.
|
||||
|
||||
Beta ingress hostnames:
|
||||
|
||||
| Service | Hostname |
|
||||
@@ -648,11 +666,11 @@ Paper ingress hostnames:
|
||||
|
||||
```
|
||||
values-beta.yaml values-paper.yaml values.yaml (base)
|
||||
Beta → Paper Trading → Production
|
||||
Beta -> Paper Trading -> Production
|
||||
Integration Simulated orders Live trading
|
||||
testing Real market data Real orders
|
||||
Pipeline OFF Pipeline ON Pipeline ON
|
||||
Trading OFF Trading ON Trading ON
|
||||
Trading ON Trading ON Trading ON
|
||||
Analytics OFF Analytics ON Analytics ON
|
||||
```
|
||||
|
||||
|
||||
@@ -0,0 +1,363 @@
|
||||
# V3 Annotation Guidelines
|
||||
|
||||
**Schema version:** 1.0.0
|
||||
**Last updated:** 2025-01-15
|
||||
|
||||
## Purpose
|
||||
|
||||
These guidelines define how human annotators and automated systems label documents in the Intelligence Pipeline v3 Gold Corpus. Every annotation must be evidence-grounded — no label is valid without a supporting evidence span traceable to the source text.
|
||||
|
||||
## Core Principles
|
||||
|
||||
1. **Evidence first.** If you cannot point to exact text that supports a label, do not apply the label.
|
||||
2. **Explicit over inferred.** Mark only what the document explicitly states in primary annotations. Inferred exposure uses a separate, lower-confidence channel.
|
||||
3. **Precision over recall.** A missed entity is preferable to a fabricated one. The pipeline uses multiple stages — later stages catch omissions.
|
||||
4. **Reproducibility.** Two annotators given the same document should produce substantially the same labels. Ambiguous cases are marked, not resolved by guess.
|
||||
|
||||
---
|
||||
|
||||
## Evidence Spans
|
||||
|
||||
### Definition
|
||||
|
||||
An evidence span is the exact substring of the source document that supports an annotation. It uses zero-based character offsets into the original (pre-chunking) document text.
|
||||
|
||||
### Rules
|
||||
|
||||
- Every entity, event, relation, numeric fact, and sentiment annotation MUST reference at least one evidence span.
|
||||
- Spans should be minimal but complete — include enough context for the label to be verifiable without the full document.
|
||||
- Overlapping spans are permitted (e.g., the same sentence supports both an entity and an event).
|
||||
- The `text` field MUST exactly match `source_text[start_char:end_char]`.
|
||||
|
||||
### Positive example
|
||||
|
||||
```
|
||||
Source: "Apple Inc. reported quarterly earnings of $1.52 per share"
|
||||
Span: start_char=0, end_char=10, text="Apple Inc."
|
||||
```
|
||||
|
||||
### Negative example
|
||||
|
||||
```
|
||||
Source: "Apple Inc. reported quarterly earnings of $1.52 per share"
|
||||
Span: start_char=0, end_char=5, text="Apple"
|
||||
```
|
||||
❌ Truncating "Apple Inc." to "Apple" loses the corporate suffix needed to distinguish from Apple Records or the fruit.
|
||||
|
||||
---
|
||||
|
||||
## Entity Annotation
|
||||
|
||||
### Entity Types
|
||||
|
||||
| Type | When to use | Example |
|
||||
|------|-------------|---------|
|
||||
| `company` | Legal entity, publicly traded firm, government agency | "Apple Inc.", "The Federal Reserve" |
|
||||
| `person` | Named individual | "Tim Cook", "Jerome Powell" |
|
||||
| `product` | Named product or service | "iPhone 16", "Azure OpenAI Service" |
|
||||
| `event` | Named event instance | "Q1 2025 earnings call" |
|
||||
| `financial_metric` | Named metric class | "EPS", "revenue", "free cash flow" |
|
||||
| `date` | Temporal expression | "Q1 2025", "January 15, 2025" |
|
||||
| `percentage` | Percentage value | "4%", "25 basis points" |
|
||||
| `currency` | Monetary value | "$1.52", "$10 billion" |
|
||||
| `relationship` | Explicit relationship mention | "subsidiary", "joint venture partner" |
|
||||
|
||||
### Canonical Resolution
|
||||
|
||||
- If an entity maps to a company in the symbol registry, set `canonical_id` and `canonical_name` (ticker).
|
||||
- If an entity is ambiguous (e.g., "Apple" could be AAPL or a fruit company), mark an ambiguity marker and set confidence below 1.0.
|
||||
- Do NOT invent canonical IDs. If not in the registry, leave `canonical_id` as null.
|
||||
|
||||
### Positive example
|
||||
|
||||
```json
|
||||
{
|
||||
"entity_type": "company",
|
||||
"literal_text": "Alphabet",
|
||||
"canonical_id": "googl-uuid",
|
||||
"canonical_name": "GOOGL",
|
||||
"confidence": 0.97
|
||||
}
|
||||
```
|
||||
|
||||
### Negative example
|
||||
|
||||
```json
|
||||
{
|
||||
"entity_type": "company",
|
||||
"literal_text": "the company",
|
||||
"canonical_id": "aapl-uuid",
|
||||
"canonical_name": "AAPL",
|
||||
"confidence": 0.90
|
||||
}
|
||||
```
|
||||
❌ "the company" is a pronoun reference, not an entity mention. Resolve coreference but annotate the actual named mention, not the pronoun.
|
||||
|
||||
---
|
||||
|
||||
## Event Classification
|
||||
|
||||
### Event Classes
|
||||
|
||||
| Class | Definition | Distinguishing criteria |
|
||||
|-------|-----------|------------------------|
|
||||
| `earnings_beat` | Reported EPS or revenue exceeds consensus | Explicit comparison to estimates |
|
||||
| `earnings_miss` | Reported EPS or revenue below consensus | Explicit comparison to estimates |
|
||||
| `guidance_raise` | Forward guidance raised vs prior or consensus | Future-looking, not historical result |
|
||||
| `guidance_cut` | Forward guidance lowered | Future-looking, not historical result |
|
||||
| `ma_announcement` | Merger, acquisition, investment, or divestiture | Transaction between entities |
|
||||
| `legal_regulatory` | Lawsuit, fine, regulatory action, or settlement | Legal or regulatory body involved |
|
||||
| `product_launch` | New product, service, or major feature announced | Not routine updates |
|
||||
| `supply_chain` | Disruption, partnership, or change in supply relationships | Affects production/delivery |
|
||||
| `rating_change` | Analyst upgrade, downgrade, or target change | From research analyst/firm |
|
||||
| `management_change` | CEO/CFO/board appointment, resignation, or removal | C-suite or board level |
|
||||
| `macro_event` | Interest rates, policy, trade, geopolitical | Not specific to one company |
|
||||
| `dividend_change` | Dividend increase, decrease, or special dividend | Shareholder distribution |
|
||||
| `buyback` | Share repurchase program announcement or completion | Capital return via buyback |
|
||||
|
||||
### Adjudication triggers for events
|
||||
|
||||
Route to the 9B adjudicator when:
|
||||
- The same facts could be classified as multiple event types (e.g., guidance_raise during an earnings call could be either earnings_beat or guidance_raise — label the most specific applicable class).
|
||||
- The event is implied but not explicitly stated.
|
||||
- The primary company is unclear.
|
||||
|
||||
### Positive example
|
||||
|
||||
```
|
||||
Source: "Apple beat earnings expectations with EPS of $1.52 vs $1.43 expected"
|
||||
Event class: earnings_beat
|
||||
Confidence: 0.98
|
||||
```
|
||||
|
||||
### Negative example
|
||||
|
||||
```
|
||||
Source: "Apple reported EPS of $1.52"
|
||||
Event class: earnings_beat
|
||||
```
|
||||
❌ Without a comparison to consensus/estimates, this is a numeric fact report, not an earnings beat. The document must provide evidence of beating expectations.
|
||||
|
||||
---
|
||||
|
||||
## Relations
|
||||
|
||||
### Relation Types
|
||||
|
||||
| Type | Subject | Object | When to use |
|
||||
|------|---------|--------|-------------|
|
||||
| `directly_affects` | Event | Company | Event explicitly names or discusses the company |
|
||||
| `inferred_exposure` | Event | Company | Exposure inferred from sector, supply chain, or competition |
|
||||
| `competes_with` | Company | Company | Competitive relationship stated or clearly implied |
|
||||
| `supplies` | Company | Company | Supply chain relationship stated |
|
||||
|
||||
### Critical distinction: directly_affects vs inferred_exposure
|
||||
|
||||
- `directly_affects`: The document **explicitly states** the company is impacted. Evidence span exists.
|
||||
- `inferred_exposure`: The impact is **reasoned** from relationships, not stated. May have weak or no direct evidence span.
|
||||
|
||||
Only `directly_affects` enters primary company extraction. `inferred_exposure` flows through the separate interpolation/propagation architecture with distinct confidence and provenance.
|
||||
|
||||
### Positive example (directly_affects)
|
||||
|
||||
```
|
||||
Source: "Microsoft announced a $10 billion investment in OpenAI"
|
||||
Relation: directly_affects(event=ma_announcement, company=Microsoft)
|
||||
Evidence: "Microsoft announced"
|
||||
```
|
||||
|
||||
### Negative example (incorrectly using directly_affects)
|
||||
|
||||
```
|
||||
Source: "Microsoft announced a $10 billion investment in OpenAI"
|
||||
Relation: directly_affects(event=ma_announcement, company=Google)
|
||||
```
|
||||
❌ Google is not mentioned in the event sentence. This should be `inferred_exposure` based on competitive relationship, with appropriate lower confidence.
|
||||
|
||||
---
|
||||
|
||||
## Numeric Facts
|
||||
|
||||
### Annotation rules
|
||||
|
||||
1. Always store both `literal_value` (exact text) and `normalized_value` (parsed number).
|
||||
2. Include `unit` (USD, %, bps, shares, etc.).
|
||||
3. Link to the subject entity when determinable.
|
||||
4. Use `predicate` to capture the semantic role: reported, expected, raised_to, cut_to, beat_by, missed_by.
|
||||
5. Include `period` when the fact references a specific time frame.
|
||||
|
||||
### Normalization conventions
|
||||
|
||||
| Literal | Normalized | Unit |
|
||||
|---------|-----------|------|
|
||||
| "$1.52" | 1.52 | USD |
|
||||
| "$94.9 billion" | 94900000000 | USD |
|
||||
| "25 basis points" | 0.25 | percentage_points |
|
||||
| "4%" | 4.0 | % |
|
||||
| "$0.26 per share" | 0.26 | USD |
|
||||
|
||||
### Positive example
|
||||
|
||||
```json
|
||||
{
|
||||
"fact_type": "eps",
|
||||
"predicate": "reported",
|
||||
"literal_value": "$1.52 per share",
|
||||
"normalized_value": 1.52,
|
||||
"unit": "USD",
|
||||
"period": {"period_type": "fiscal_quarter", "fiscal_year": 2025, "fiscal_quarter": 1}
|
||||
}
|
||||
```
|
||||
|
||||
### Negative example
|
||||
|
||||
```json
|
||||
{
|
||||
"fact_type": "eps",
|
||||
"predicate": "reported",
|
||||
"literal_value": "$1.52 per share",
|
||||
"normalized_value": 152,
|
||||
"unit": "cents"
|
||||
}
|
||||
```
|
||||
❌ While $1.52 = 152 cents, always normalize to the unit stated in the source. Conversion to a different unit introduces potential confusion.
|
||||
|
||||
---
|
||||
|
||||
## Sentiment
|
||||
|
||||
### Rules
|
||||
|
||||
1. Sentiment is **company-specific**, not document-level. A single article can have positive sentiment for one company and negative for another.
|
||||
2. Annotate probability distributions (positive, negative, neutral) that sum to 1.0.
|
||||
3. `mixed` label is used when evidence groups disagree — it is computed from evidence-group-level disagreement, NOT an unconstrained fourth class.
|
||||
4. The label should reflect the dominant probability.
|
||||
|
||||
### When to label "mixed"
|
||||
|
||||
Label `mixed` when:
|
||||
- Different paragraphs contain opposing sentiment for the same company
|
||||
- The same fact has both positive and negative implications (e.g., restructuring = cost cuts but also layoffs)
|
||||
- Analyst opinions explicitly disagree within the document
|
||||
|
||||
Do NOT label `mixed` when:
|
||||
- Sentiment is merely uncertain or mild — that's `neutral` with lower confidence
|
||||
- The document discusses multiple companies with different sentiments — annotate separately per company
|
||||
|
||||
### Positive example
|
||||
|
||||
```json
|
||||
{
|
||||
"label": "mixed",
|
||||
"positive_probability": 0.40,
|
||||
"negative_probability": 0.45,
|
||||
"neutral_probability": 0.15,
|
||||
"evidence_ids": ["ev-pressure", "ev-validation"]
|
||||
}
|
||||
```
|
||||
(Article says AI investment pressures cloud revenue but validates the broader thesis)
|
||||
|
||||
### Negative example
|
||||
|
||||
```json
|
||||
{
|
||||
"label": "mixed",
|
||||
"positive_probability": 0.85,
|
||||
"negative_probability": 0.05,
|
||||
"neutral_probability": 0.10
|
||||
}
|
||||
```
|
||||
❌ When positive_probability dominates at 0.85, the label should be `positive`, not `mixed`. Mixed requires genuine disagreement in evidence.
|
||||
|
||||
---
|
||||
|
||||
## Direct Effects vs Inferred Exposure
|
||||
|
||||
### Direct Effects
|
||||
|
||||
A direct effect means the document **explicitly states or clearly demonstrates** that an event impacts a specific company.
|
||||
|
||||
**Criteria:**
|
||||
- The company is named in the same sentence or paragraph as the event
|
||||
- The causal link is stated, not inferred
|
||||
- Evidence span directly connects event to company
|
||||
|
||||
### Inferred Exposure
|
||||
|
||||
Inferred exposure captures **reasoned but unstated** impacts on companies.
|
||||
|
||||
**Criteria:**
|
||||
- The company is NOT explicitly linked to the event in the source text
|
||||
- The connection comes from known relationships (competitor, supplier, sector peer)
|
||||
- Confidence should be lower than direct effects (typically 0.5–0.8)
|
||||
- Requires `reasoning` field explaining the inference chain
|
||||
|
||||
### Adjudication routing
|
||||
|
||||
When it's unclear whether an effect is direct or inferred, mark an ambiguity marker with type `implied_causal_impact` and route to the 9B adjudicator.
|
||||
|
||||
---
|
||||
|
||||
## Ambiguity Markers
|
||||
|
||||
### When to flag
|
||||
|
||||
Flag ambiguity when:
|
||||
- An alias resolves to multiple candidate companies (`unresolved_alias`)
|
||||
- Multiple companies could be the primary subject (`multiple_primary_companies`)
|
||||
- Numeric facts within the same document contradict each other (`contradictory_numeric_facts`)
|
||||
- Sentiment evidence points in opposing directions for the same company (`conflicting_sentiment`)
|
||||
- Impact is implied through causal chain, not stated (`implied_causal_impact`)
|
||||
- Guidance must be compared to consensus to determine direction (`guidance_vs_consensus_requires_reasoning`)
|
||||
- A required field cannot be determined from available evidence (`material_field_missing`)
|
||||
- Evidence covers less than the minimum threshold for confident extraction (`evidence_coverage_below_threshold`)
|
||||
- Calibrated confidence falls below the routing threshold (`calibrated_confidence_below_threshold`)
|
||||
- A relation spans multiple document chunks (`long_document_cross_chunk_relation`)
|
||||
|
||||
### Severity levels
|
||||
|
||||
- **low**: The annotation is likely correct but has reduced certainty. Fast path may proceed with a confidence penalty.
|
||||
- **medium**: The annotation requires review. Routes to adjudication by default.
|
||||
- **high**: The annotation cannot be reliably made without semantic reasoning. Always routes to adjudication.
|
||||
|
||||
---
|
||||
|
||||
## Safety-Critical Fields
|
||||
|
||||
The following fields are **safety-critical** for promotion gates. Errors in these fields can directly cause incorrect trading decisions:
|
||||
|
||||
| Field | Why it's critical | Minimum promotion gate |
|
||||
|-------|-------------------|----------------------|
|
||||
| Company identity (ticker) | Wrong ticker = trade on wrong security | Precision ≥ 0.95, Recall ≥ 0.90 |
|
||||
| Event class | Misclassifying beat/miss inverts signal direction | Macro-F1 ≥ 0.85 |
|
||||
| Sentiment direction | Wrong sentiment → wrong position direction | Direction accuracy ≥ 0.90 |
|
||||
| Numeric fact values | Wrong magnitude affects impact estimation | Tolerance match ≥ 0.92 |
|
||||
| Direct effect attribution | Wrong company attribution creates false signals | Precision ≥ 0.93 |
|
||||
| Evidence support | Unsupported claims are unverifiable | Support rate ≥ 0.95 |
|
||||
| Confidence calibration | Overconfidence bypasses review | ECE ≤ 0.05 |
|
||||
|
||||
Annotators must pay special attention to these fields. During review, any error in a safety-critical field requires correction before the annotation can receive "gold" status.
|
||||
|
||||
---
|
||||
|
||||
## Annotation Workflow
|
||||
|
||||
1. **First pass:** Identify all entities and evidence spans
|
||||
2. **Second pass:** Classify events and link to companies
|
||||
3. **Third pass:** Extract numeric facts with periods
|
||||
4. **Fourth pass:** Assess per-company sentiment
|
||||
5. **Fifth pass:** Identify relations, direct effects, and inferred exposures
|
||||
6. **Sixth pass:** Flag ambiguities and set confidence levels
|
||||
7. **Review:** Senior annotator validates safety-critical fields
|
||||
|
||||
### Inter-annotator agreement
|
||||
|
||||
Hard cases (flagged with ambiguity markers) receive double annotation. Inter-annotator agreement is measured per field type using Cohen's kappa. Target: κ ≥ 0.80 for entity and event labels, κ ≥ 0.70 for relations and sentiment.
|
||||
|
||||
---
|
||||
|
||||
## Version History
|
||||
|
||||
| Version | Date | Changes |
|
||||
|---------|------|---------|
|
||||
| 1.0.0 | 2025-01-15 | Initial schema and guidelines |
|
||||
@@ -0,0 +1,84 @@
|
||||
# Session Context — July 11, 2026
|
||||
|
||||
## Current State
|
||||
|
||||
### Active Namespace: `stonks-beta`
|
||||
- This is the ONLY namespace that should be running
|
||||
- `stonks-oracle` namespace has been scaled to 0 replicas (all deployments)
|
||||
- Dashboard: `https://stonks-beta.celestium.life`
|
||||
- API: `https://stonks-api-beta.celestium.life`
|
||||
|
||||
### What Was Done This Session
|
||||
|
||||
#### 1. Pipeline Health Fixes (spec: `.kiro/specs/pipeline-health-fixes/`)
|
||||
All implemented and deployed:
|
||||
- **Stuck Parsed Docs**: `STALE_PARSED_THRESHOLD_MINUTES` 240→30, `LIMIT` 100→500, `_ENQUEUED_TTL` 14400→3600 (`services/scheduler/app.py`)
|
||||
- **Price Fallback**: Added 24h market_snapshots time-window fallback in `create_prediction_snapshot()` (`services/validation/prediction_snapshot.py`)
|
||||
- **Sentiment Normalization**: Added `normalize_impact_scores()` z-score function (`services/aggregation/scoring.py`) + integrated into `aggregate_company_window()` (`services/aggregation/worker.py`)
|
||||
- **Signal Engine**: Replicas set to 0 in all Helm values files
|
||||
- **Quality Gate**: `max_snapshot_age_hours` 24→48 (`services/trading/model_quality_gate.py`)
|
||||
- **Backfill script**: `scripts/backfill_snapshot_prices.py` (one-time, not yet run on beta)
|
||||
|
||||
#### 2. Extractor Null-Field Fix
|
||||
- `services/extractor/schemas.py`: `_normalize_extraction_data()` now handles `None` values (not just missing keys) and filters out company entries with empty ticker
|
||||
- Test updated: `tests/test_extractor_schemas.py::test_validate_semantic_missing_ticker_is_error`
|
||||
|
||||
#### 3. Macro Doc Status Fix
|
||||
- `services/extractor/main.py`: `_process_macro_classification()` now updates document status to 'extracted' on success, 'extraction_failed' on error
|
||||
- Beta DB: manually fixed 1849 stuck macro docs (UPDATE status='extracted' WHERE id IN global_events)
|
||||
|
||||
#### 4. Dashboard Fix
|
||||
- `frontend/src/pages/OpsPipeline.tsx`: Document Stages now uses time-filtered `/health` data (consistent with other sections), all-time from SSE stream shown as subtitle, time range labels added to all sections
|
||||
|
||||
#### 5. CI/CD DNS Fix
|
||||
- `.woodpecker/*.yml`: All 5 pipeline files now use `clone.git.settings.remote: http://10.43.73.77:3000/admin/stonks-oracle.git` (Gitea ClusterIP directly, bypasses DNS)
|
||||
- CoreDNS: scaled to 4 replicas, `forward . 192.168.42.1`, `dnsPolicy: None` with `nameservers: [192.168.42.1]`
|
||||
- Woodpecker: `WOODPECKER_BACKEND_K8S_DNS_CONFIG` has `nameservers:[10.43.0.10]` + searches including `git-server.svc.cluster.local`
|
||||
|
||||
### Known Issues / TODO
|
||||
|
||||
1. **`stonks-oracle` namespace**: Scaled to 0 but still exists with stale data (42K extraction queue in Redis DB 0). Could be cleaned up or deleted entirely.
|
||||
|
||||
2. **Thesis Rewriter agent**: Was hammering vLLM from stonks-oracle namespace (5600+ calls/24h). Now stopped since namespace is scaled down. If it was also running in beta, check if recommendation service is calling vLLM for thesis rewrites excessively.
|
||||
|
||||
3. **`AxionML/Qwen3.5-9B-NVFP4` requests**: Something external is hitting vLLM with a model that doesn't exist (404s). Not from our pipeline — likely Open WebUI or another tool on the network configured with wrong model name. Source IP: goes through `vllm-metrics` nginx proxy (`10.42.1.155`).
|
||||
|
||||
4. **GitHub mirror**: `finalize.yml` mirror-github step fails (SSH key or DNS). Has `failure: ignore` so non-blocking. Needs `github_ssh_key` secret configured in Woodpecker.
|
||||
|
||||
5. **OpsPipeline dashboard**: Numbers now show time-filtered data. The "Document Stages" section shows counts from the selected time window (default 24h), with all-time totals as subtle subtitles. Currently beta shows: extracted=5417, low_quality=1659, parsed=15.
|
||||
|
||||
6. **Aggregation not generating trends on weekends**: Expected — market hours check prevents weekend trend generation. Will resume Monday.
|
||||
|
||||
7. **15 docs still in `parsed` status**: These are likely fresh ingests waiting for the next extraction cycle. Not stuck.
|
||||
|
||||
### Agent Performance (beta, last 24h as of session end)
|
||||
- Document Intelligence Extractor: 33 calls, 94% success, avg 11.4s, conf 0.794
|
||||
- Global Event Classifier: 81 calls, 99% success, avg 4.2s, conf 0.745
|
||||
- Thesis Rewriter: 5603 calls, 100% success, avg 2.5s (from stonks-oracle before shutdown)
|
||||
- Report Summarizer: 6 calls, 100% success, avg 6.9s
|
||||
|
||||
### Infrastructure
|
||||
- k3s cluster: 4 NixOS nodes (gremlin-1 through gremlin-4)
|
||||
- vLLM: `vllm-service` namespace, model `numind/NuExtract3`, 4070 Ti Super 16GB
|
||||
- CoreDNS: 4 replicas, `forward . 192.168.42.1`
|
||||
- Redis: DB 0 = stonks-oracle (stale), DB 1 = stonks-beta (active)
|
||||
- PostgreSQL: shared instance, both namespaces use same DB server (different databases? or same? — needs verification)
|
||||
- Gitea: `git-server` namespace, ClusterIP 10.43.73.77:3000, NodePort 30300
|
||||
- Woodpecker: `woodpecker` namespace, kubernetes backend, 2 agents
|
||||
|
||||
### Key Files Modified
|
||||
```
|
||||
services/scheduler/app.py — recovery thresholds + batch limit
|
||||
services/validation/prediction_snapshot.py — 24h price fallback
|
||||
services/aggregation/scoring.py — normalize_impact_scores()
|
||||
services/aggregation/worker.py — normalization integration
|
||||
services/trading/model_quality_gate.py — 48h threshold
|
||||
services/extractor/schemas.py — null field handling
|
||||
services/extractor/main.py — macro doc status update
|
||||
frontend/src/pages/OpsPipeline.tsx — dashboard fix
|
||||
scripts/backfill_snapshot_prices.py — new script
|
||||
tests/test_pbt_pipeline_health_*.py — PBT tests
|
||||
tests/test_extractor_schemas.py — updated test
|
||||
infra/helm/stonks-oracle/values*.yaml — signal-engine replicas
|
||||
.woodpecker/*.yml — ClusterIP clone fix
|
||||
```
|
||||
@@ -20,7 +20,7 @@ scrape_configs:
|
||||
scrape_interval: 15s
|
||||
scrape_timeout: 10s
|
||||
metrics_path: /metrics
|
||||
static_targets:
|
||||
static_configs:
|
||||
- targets:
|
||||
# Docker Compose
|
||||
- "query-api:8000"
|
||||
@@ -124,6 +124,7 @@ All metrics are defined in `services/shared/metrics.py`. Metric names use the `s
|
||||
| `stonks_orders_rejected_total` | Counter | `reason_category` | Orders rejected before broker submission |
|
||||
| `stonks_orders_filled_total` | Counter | `side` | Orders filled by broker |
|
||||
| `stonks_orders_duplicates_prevented_total` | Counter | `detected_via` | Duplicate orders prevented by idempotency checks |
|
||||
| `stonks_orders_clamped_total` | Counter | — | Orders auto-clamped to fit within position limits |
|
||||
| `stonks_risk_evaluations_total` | Counter | `result` | Risk evaluations performed |
|
||||
| `stonks_risk_check_failures_total` | Counter | `check_name` | Individual risk check failures |
|
||||
| `stonks_positions_synced_total` | Counter | — | Position sync operations completed |
|
||||
|
||||
@@ -0,0 +1,144 @@
|
||||
# Stonks Oracle — What It Is and What It Does
|
||||
|
||||
## The One-Liner
|
||||
|
||||
Stonks Oracle is an autonomous market intelligence system that reads the news so you don't have to, forms a view on 50 publicly traded companies, and paper-trades that view — then grades its own homework.
|
||||
|
||||
---
|
||||
|
||||
## The Problem It Solves
|
||||
|
||||
Markets are noisy. Every day, hundreds of news articles, SEC filings, earnings transcripts, and geopolitical headlines hit the wire. A human analyst covering even a dozen names struggles to weigh all of it in real time. Most retail and even some institutional desks end up reacting to headlines rather than synthesizing the full picture.
|
||||
|
||||
Stonks Oracle replaces that manual synthesis with an always-on pipeline:
|
||||
|
||||
1. **It reads everything.** News articles, 10-K/10-Q filings, earnings calls, press releases, and macro/geopolitical headlines — ingested automatically on a schedule.
|
||||
2. **It extracts structured intelligence.** A local AI model reads each document and pulls out: which companies are mentioned, the sentiment (bullish / bearish / neutral), the catalyst type (earnings, product launch, regulatory action, M&A, etc.), impact horizon (same-day through 90 days), key facts, and material risks.
|
||||
3. **It forms a view.** Those individual extractions are aggregated into rolling trend summaries per company, refreshed continuously. The system flags contradictions (e.g., one filing is bullish but a news article is bearish) and tracks confidence based on evidence depth.
|
||||
4. **It decides whether to trade.** When confidence is high enough, contradiction is low, and evidence is fresh, it issues a buy or sell recommendation — with a full written thesis explaining why.
|
||||
5. **It executes paper trades.** An autonomous trading engine places orders through Alpaca's paper-trading system. Position sizing, stop-losses, take-profits, sector concentration limits, and circuit breakers are all built in.
|
||||
6. **It measures itself.** Every prediction is frozen at the moment it's made, then checked against actual price movements days and weeks later. The system tracks its own win rate, calibration, and whether it's beating SPY.
|
||||
|
||||
---
|
||||
|
||||
## The Universe
|
||||
|
||||
50 companies across 10 sectors:
|
||||
|
||||
| Sector | Examples |
|
||||
|--------|----------|
|
||||
| Technology | AAPL, MSFT, NVDA, GOOGL, META |
|
||||
| Consumer Cyclical | AMZN, TSLA, NKE, SBUX |
|
||||
| Financial Services | JPM, GS, V, MA |
|
||||
| Healthcare | JNJ, UNH, PFE, LLY |
|
||||
| Energy | XOM, CVX, COP |
|
||||
| Communication Services | NFLX, DIS, T |
|
||||
| Industrials | CAT, BA, UPS |
|
||||
| Consumer Defensive | PG, KO, WMT |
|
||||
| Real Estate | AMT, PLD |
|
||||
| Utilities | NEE, DUK |
|
||||
|
||||
46 competitor relationships are defined (direct rivals, same-sector peers, overlapping products, supply chain adjacencies) so the system can propagate signals — e.g., if a semiconductor shortage hits one chipmaker, the system assesses exposure for its competitors and supply chain partners.
|
||||
|
||||
---
|
||||
|
||||
## The Three Signal Layers
|
||||
|
||||
Think of these as three analysts sitting at the same desk, each watching a different feed:
|
||||
|
||||
### Layer 1 — Company-Specific Intelligence
|
||||
|
||||
The bread and butter. Every news article and filing about a specific company gets scored for sentiment, impact magnitude, and time horizon. These signals are weighted by recency (yesterday's earnings matter more than last month's), source credibility, and novelty (the fifth article repeating the same news adds less information than the first).
|
||||
|
||||
Trend summaries roll up across five windows: intraday, 1 day, 7 days, 30 days, and 90 days — giving both a "what's happening right now" and a "what's the longer arc" view.
|
||||
|
||||
### Layer 2 — Macro & Geopolitical
|
||||
|
||||
Global events (trade wars, rate decisions, geopolitical crises, commodity shocks) are classified by impact type and severity. Each company has an exposure profile — geographic revenue mix, supply chain regions, commodity dependencies — that maps macro events down to company-level impact scores.
|
||||
|
||||
A tariff announcement on Chinese imports doesn't affect all 50 companies equally. Apple with its Chinese manufacturing exposure gets a higher impact score than Procter & Gamble with largely domestic supply chains.
|
||||
|
||||
### Layer 3 — Competitive & Historical Patterns
|
||||
|
||||
The system mines its own history: when this type of catalyst (say, an earnings beat) happened to this company in the past, what happened to the stock? What happened to its competitors? If NVIDIA reports a blowout quarter, does AMD tend to sell off or rally in sympathy?
|
||||
|
||||
This layer also tracks major corporate actions (M&A, restructurings, leadership changes) and propagates their implications across the competitive web.
|
||||
|
||||
**Safety rule:** The system never trades on macro or competitive signals alone. If there's no company-specific evidence supporting the thesis, the recommendation is downgraded to informational only.
|
||||
|
||||
---
|
||||
|
||||
## How a Trade Happens
|
||||
|
||||
Here's the chain from "news article published" to "paper order placed":
|
||||
|
||||
1. **Ingestion** — The article is fetched, deduplicated, and stored.
|
||||
2. **Parsing** — Raw HTML is cleaned, boilerplate is stripped, quality is scored.
|
||||
3. **Extraction** — The AI model reads the cleaned text and produces structured JSON: tickers mentioned, sentiment, catalysts, key facts, risks.
|
||||
4. **Aggregation** — The new extraction is merged into rolling trend summaries for each mentioned company. Confidence, contradiction, and evidence depth are recalculated.
|
||||
5. **Recommendation** — If the trend passes quality filters (enough evidence, high enough confidence, low enough contradiction, not stale), a BUY or SELL recommendation is generated with a written thesis.
|
||||
6. **Risk checks** — The trading engine asks: Is the circuit breaker tripped? Is the market open? Do I already have too many positions? Is this sector already overweight? Are earnings in the next 48 hours?
|
||||
7. **Position sizing** — Dollar amount is computed from confidence, portfolio heat, and the current risk tier (conservative / moderate / aggressive — auto-adjusted based on trailing performance).
|
||||
8. **Execution** — The order goes to Alpaca's paper-trading API. Stop-loss and take-profit levels are set automatically based on the stock's recent volatility.
|
||||
9. **Monitoring** — Open positions are tracked with trailing stops. If a position declines past its stop, it's closed. If it hits the take-profit target, it's closed.
|
||||
10. **Scoring** — Days later, the prediction is evaluated against the actual price move. Did the call go the right way? Did the confidence track reality?
|
||||
|
||||
---
|
||||
|
||||
## Risk Management (Built In, Not Bolted On)
|
||||
|
||||
- **Circuit breakers** — If daily losses exceed a threshold or a single position loses too much, all trading halts automatically.
|
||||
- **Position caps** — No single position can consume more than a set percentage of the portfolio.
|
||||
- **Sector concentration limits** — The system won't pile into one sector even if all signals are bullish.
|
||||
- **Correlation awareness** — New positions are rejected if they'd push portfolio correlation too high.
|
||||
- **Earnings blackout** — Position sizes are reduced or skipped entirely within 48 hours of an earnings announcement.
|
||||
- **Reserve pool** — Profits are partially siphoned into an emergency liquidity reserve.
|
||||
- **Risk tier auto-adjustment** — The system evaluates its own Sharpe ratio, drawdown, and win rate daily and shifts between conservative, moderate, and aggressive modes.
|
||||
|
||||
---
|
||||
|
||||
## Self-Grading: The Validation Loop
|
||||
|
||||
Most trading systems tell you their view. Few systematically check whether that view was right.
|
||||
|
||||
Stonks Oracle captures every prediction as an immutable snapshot — the thesis, the confidence, the price at the time, the evidence cited. Then it waits. After the prediction's time horizon elapses (1 day, 7 days, 30 days), it compares the predicted direction against the actual price movement and computes:
|
||||
|
||||
- **Win rate** — What fraction of directional calls were correct?
|
||||
- **Calibration** — When the system says "70% confident bullish," does the stock actually go up ~70% of the time? (If it only goes up 50% of the time, the system is overconfident.)
|
||||
- **Information coefficient** — Does the system's score have any linear correlation with actual returns?
|
||||
- **Excess return vs. SPY** — Is it adding alpha, or would you be better off in an index fund?
|
||||
- **Source attribution** — Which news sources and signal types actually contribute to correct predictions? Which are noise?
|
||||
|
||||
If model quality drops below defined thresholds, a safety gate prevents the system from upgrading recommendations from "informational" to "paper eligible" — it forces itself to the sidelines until accuracy recovers.
|
||||
|
||||
---
|
||||
|
||||
## The Dashboard
|
||||
|
||||
A web-based interface lets you see everything the system sees:
|
||||
|
||||
- **Home** — Portfolio value, daily P&L, risk tier, active alerts.
|
||||
- **Companies** — The tracked universe with current trend summaries and signal strength.
|
||||
- **Documents** — Every ingested article and filing, with the AI's structured extraction visible.
|
||||
- **Trends** — Per-company trend charts across all time windows, with evidence chains you can click through.
|
||||
- **Recommendations** — Active and historical recommendations with full theses and risk classifications.
|
||||
- **Trading** — The engine's status: open positions, reserve pool, circuit breaker state, portfolio heat map.
|
||||
- **Orders & Positions** — Full trade blotter with execution details.
|
||||
- **Macro Events** — Global event timeline showing what the system is tracking at the geopolitical level.
|
||||
- **Reports** — AI-generated daily and weekly performance summaries.
|
||||
- **Model Performance** — Calibration curves, win rate trends, source reliability scores.
|
||||
- **SQL Explorer** — Ad-hoc queries against the full analytical data warehouse, with a chart builder.
|
||||
|
||||
---
|
||||
|
||||
## What It Is Not
|
||||
|
||||
- **Not a live trading system (yet).** All trades are paper trades through Alpaca's sandbox. The architecture supports live execution, but safety gates and validation must demonstrate consistent edge before real money is at risk.
|
||||
- **Not a black box.** Every recommendation includes a full thesis, every trade has a decision trace, every prediction links back to the specific evidence that drove it.
|
||||
- **Not a prediction guarantee.** Markets are hard. The system's value is in disciplined synthesis, consistent process, and honest self-measurement — not in claiming to always be right.
|
||||
|
||||
---
|
||||
|
||||
## Where It's Headed
|
||||
|
||||
Active development is upgrading the signal math from rule-based heuristics to probabilistic Bayesian inference — running both approaches in parallel, comparing their verdicts, and using the disagreements as training signals for continuous improvement. The goal is a system that not only reads the market but learns from its own track record which types of evidence, in which market regimes, actually predict future price moves.
|
||||
+117
-10
@@ -41,6 +41,7 @@ All queues use the `stonks:queue:<name>` key pattern (configurable via `DEPLOY_S
|
||||
| `recommendation` | `stonks:queue:recommendation` | Aggregation | Recommendation |
|
||||
| `broker_orders` | `stonks:queue:broker_orders` | Trading Engine, Trading API | Broker Adapter |
|
||||
| `lake_publish` | `stonks:queue:lake_publish` | Various services | Lake Publisher |
|
||||
| `report_generation` | `stonks:queue:report_generation` | Scheduler | Scheduler (inline consumer) |
|
||||
|
||||
### Queue Message Schemas
|
||||
|
||||
@@ -131,11 +132,20 @@ All queues use the `stonks:queue:<name>` key pattern (configurable via `DEPLOY_S
|
||||
}
|
||||
```
|
||||
|
||||
**Report Generation Job** (`stonks:queue:report_generation`):
|
||||
```json
|
||||
{
|
||||
"report_type": "daily | weekly",
|
||||
"period_start": "2025-01-01",
|
||||
"period_end": "2025-01-01"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1. Scheduler
|
||||
|
||||
**Purpose**: Triggers ingestion cycles for tracked companies and sources on a configurable cadence. Polls the symbol registry for active companies and their configured sources, respects per-source polling intervals and backoff windows, coordinates rate limits across source types, and enqueues ingestion jobs for downstream workers. Also runs periodic maintenance: stale document recovery, failed extraction retries, and data retention cleanup.
|
||||
**Purpose**: Triggers ingestion cycles for tracked companies and sources on a configurable cadence. Polls the symbol registry for active companies and their configured sources, respects per-source polling intervals and backoff windows, coordinates rate limits across source types, and enqueues ingestion jobs for downstream workers. Also runs periodic maintenance: stale document recovery, failed extraction retries, data retention cleanup, periodic aggregation re-runs, and automated report generation (daily/weekly).
|
||||
|
||||
**Entry Point**: `services.scheduler.app`
|
||||
|
||||
@@ -176,12 +186,16 @@ All queues use the `stonks:queue:<name>` key pattern (configurable via `DEPLOY_S
|
||||
| `recommendations` | Write (delete) | Retention cleanup |
|
||||
| `order_events` | Write (delete) | Retention cleanup |
|
||||
| `model_performance_metrics` | Write (delete) | Retention cleanup |
|
||||
| `ingestion_runs` | Write (delete) | Retention cleanup |
|
||||
| `trading_reports` | Write | Report generation storage |
|
||||
|
||||
### Redis Queues
|
||||
|
||||
| Direction | Queue | Purpose |
|
||||
|---|---|---|
|
||||
| Publish | `stonks:queue:ingestion` | Enqueue ingestion jobs for due sources |
|
||||
| Publish | `stonks:queue:aggregation` | Periodic aggregation re-runs |
|
||||
| Publish/Consume | `stonks:queue:report_generation` | Enqueue and consume report generation jobs |
|
||||
| Read | `stonks:pipeline:enabled` | Pipeline toggle (skip cycle if `"0"`) |
|
||||
| Read/Write | `stonks:lock:scheduler_cycle` | Distributed lock for single-writer |
|
||||
| Read/Write | `stonks:ratelimit:*` | Per-source-type and global Polygon rate limits |
|
||||
@@ -195,6 +209,8 @@ All queues use the `stonks:queue:<name>` key pattern (configurable via `DEPLOY_S
|
||||
- **Stale document recovery**: Every ~5 minutes, re-enqueues documents stuck in `parsed` status for >240 minutes.
|
||||
- **Failed extraction retry**: Every ~10 minutes, re-enqueues `extraction_failed` documents older than 60 minutes.
|
||||
- **Data retention cleanup**: Every ~25 minutes, deletes old rows from 10 tables with configurable retention windows (14–90 days).
|
||||
- **Periodic aggregation**: Re-enqueues aggregation jobs for all active tickers to keep trend summaries fresh.
|
||||
- **Report generation**: Enqueues daily and weekly report jobs on schedule; consumes them inline via `process_report_job` with retry logic (3 attempts, exponential backoff 30s/60s/120s).
|
||||
|
||||
---
|
||||
|
||||
@@ -281,7 +297,7 @@ None — this service is purely HTTP-driven.
|
||||
### MinIO Buckets
|
||||
|
||||
- `stonks-raw-market` — Raw market data JSON
|
||||
- `stonks-raw-news` — Raw news article JSON
|
||||
- `stonks-raw-news` — Raw news article JSON (also used for macro news)
|
||||
- `stonks-raw-filings` — Raw SEC filing data
|
||||
- `stonks-normalized` — Normalized text (written by parser)
|
||||
|
||||
@@ -296,6 +312,13 @@ None — this service is purely HTTP-driven.
|
||||
| `broker` | `AlpacaBrokerAdapter` | Alpaca |
|
||||
| `macro_news` | `MacroNewsAdapter` | Polygon.io |
|
||||
|
||||
### Key Behaviors
|
||||
|
||||
- Macro news jobs (`source_type=macro_news`) may lack a `company_id` — the worker handles this gracefully
|
||||
- Macro news documents are typed as `macro_event` so the parser routes them to the macro classification queue
|
||||
- Duplicate documents detected via content hash are linked to the current company (except for `macro_news`)
|
||||
- Tracks `last_published_at` per source to fetch only newer articles on subsequent runs
|
||||
|
||||
---
|
||||
|
||||
## 4. Parser
|
||||
@@ -349,7 +372,7 @@ None — this service is purely HTTP-driven.
|
||||
|
||||
## 5. Extractor
|
||||
|
||||
**Purpose**: Performs LLM-based intelligence extraction from documents using Ollama. Handles two pipelines: (1) standard document extraction producing `DocumentIntelligence` with per-company impact records, and (2) macro event classification producing `GlobalEventSchema` with company-level macro impact interpolation. Supports AI agent configuration with variant-based A/B testing.
|
||||
**Purpose**: Performs LLM-based intelligence extraction from documents using Ollama or a remote vLLM inference server. Handles two pipelines: (1) standard document extraction producing `DocumentIntelligence` with per-company impact records, and (2) macro event classification producing `GlobalEventSchema` with company-level macro impact interpolation. Supports AI agent configuration with variant-based A/B testing and provider routing (Ollama or vLLM).
|
||||
|
||||
**Entry Point**: `services.extractor.main`
|
||||
|
||||
@@ -363,9 +386,16 @@ None — this service is purely HTTP-driven.
|
||||
| `REDIS_*` | _(see shared)_ | Redis connection |
|
||||
| `MINIO_*` | _(see shared)_ | MinIO connection |
|
||||
| `OLLAMA_BASE_URL` | `http://localhost:11434` | Ollama API endpoint |
|
||||
| `OLLAMA_MODEL` | `qwen3.5:9b` | Default LLM model |
|
||||
| `OLLAMA_MODEL` | `qwen3.5:9b` | Default Ollama model |
|
||||
| `OLLAMA_TIMEOUT` | `120` | Request timeout (seconds) |
|
||||
| `OLLAMA_MAX_RETRIES` | `2` | Max retry attempts |
|
||||
| `VLLM_BASE_URL` | `http://192.168.42.254:8000` | vLLM inference server endpoint |
|
||||
| `VLLM_MODEL` | `RedHatAI/Qwen3.6-35B-A3B-NVFP4` | Default vLLM model |
|
||||
| `VLLM_TIMEOUT` | `120` | vLLM request timeout (seconds) |
|
||||
| `VLLM_MAX_RETRIES` | `2` | vLLM max retry attempts |
|
||||
| `VLLM_MAX_TOKENS` | `4096` | vLLM max output tokens |
|
||||
| `VLLM_TEMPERATURE` | `0.7` | vLLM sampling temperature |
|
||||
| `VLLM_API_KEY` | _(empty)_ | Optional API key for authenticated vLLM deployments |
|
||||
| `MACRO_CONFIDENCE_THRESHOLD` | `0.4` | Minimum confidence for macro event inclusion |
|
||||
| `LOG_LEVEL` | `INFO` | Logging level |
|
||||
|
||||
@@ -395,6 +425,7 @@ None — this service is purely HTTP-driven.
|
||||
|
||||
### Key Behaviors
|
||||
|
||||
- **LLM provider routing**: The `AgentConfigResolver` resolves agent configuration from the DB, including a `model_provider` field (`"ollama"` or `"vllm"`). The `build_llm_client` factory returns the appropriate client (`OllamaClient` or `VLLMClient`).
|
||||
- Alternates between macro and extraction queues (1 macro per 3 jobs) to prevent starvation
|
||||
- Resolves agent configuration from DB with 60-second TTL cache (`AgentConfigResolver`)
|
||||
- Supports separate models for document extraction and event classification
|
||||
@@ -565,7 +596,7 @@ None — this service is purely HTTP-driven.
|
||||
| `risk_tier_history` | Read/Write | Risk tier change audit trail |
|
||||
| `circuit_breaker_events` | Read/Write | Circuit breaker trigger/reset events |
|
||||
| `positions` | Read | Current open positions |
|
||||
| `position_stop_levels` | Read/Write | Stop-loss and take-profit levels |
|
||||
| `position_stop_levels` | Read/Write | Stop-loss and take-profit levels per position |
|
||||
| `orders` | Read | Order history for dedup |
|
||||
| `backtest_runs` | Read/Write | Backtest configuration and results |
|
||||
| `backtest_trades` | Read/Write | Individual trades within a backtest |
|
||||
@@ -652,7 +683,7 @@ None — called synchronously by the broker adapter and via HTTP.
|
||||
| `positions` | Write (upsert) | Sync positions from Alpaca |
|
||||
| `broker_accounts` | Write (upsert) | Register/update broker account |
|
||||
| `daily_risk_snapshots` | Read | Daily portfolio state for risk evaluation |
|
||||
| `risk_configs` | Read | Active risk configuration |
|
||||
| `risk_configs` | Read | Active risk configuration for order evaluation |
|
||||
| `approval_requests` | Write | Create approval requests for gated orders |
|
||||
| `audit_events` | Write | Full audit trail |
|
||||
|
||||
@@ -728,7 +759,7 @@ None — called synchronously by the broker adapter and via HTTP.
|
||||
|
||||
## 12. Query API
|
||||
|
||||
**Purpose**: Read-only FastAPI service for analytics, evidence drill-down, and admin controls. Serves the React dashboard and external integrations with endpoints for companies, documents, trends, recommendations, orders, positions, portfolio metrics, global events, macro impacts, competitive signals, trend projections, AI agents, dead-letter queues, pipeline control, SQL explorer, saved queries, audit trail, DevOps metrics, and Prometheus metrics.
|
||||
**Purpose**: Read-only FastAPI service for analytics, evidence drill-down, and admin controls. Serves the React dashboard and external integrations with endpoints for companies, documents, trends, recommendations, orders, positions, portfolio metrics, global events, macro impacts, competitive signals, trend projections, AI agents, dead-letter queues, pipeline control, SQL explorer, saved queries, audit trail, DevOps metrics, Prometheus metrics, model validation, and trading reports.
|
||||
|
||||
**Entry Point**: `services.api.app` (FastAPI)
|
||||
|
||||
@@ -745,6 +776,7 @@ None — called synchronously by the broker adapter and via HTTP.
|
||||
| `TRINO_PORT` | `8080` | Trino port |
|
||||
| `TRINO_CATALOG` | `lakehouse` | Trino catalog |
|
||||
| `TRINO_SCHEMA` | `stonks` | Trino schema |
|
||||
| `TRINO_ICEBERG_CATALOG` | `iceberg` | Trino Iceberg catalog |
|
||||
| `LOG_LEVEL` | `INFO` | Logging level |
|
||||
|
||||
### Database Tables
|
||||
@@ -757,9 +789,9 @@ The Query API reads from nearly all tables in the database, including:
|
||||
| `sources` | Source configurations |
|
||||
| `documents`, `document_company_mentions` | Document timelines |
|
||||
| `document_intelligence`, `document_impact_records` | Intelligence extraction results |
|
||||
| `trend_windows`, `trend_history`, `trend_projections` | Trend summaries and projections |
|
||||
| `trend_windows`, `trend_history`, `trend_projections`, `trend_evidence` | Trend summaries and projections |
|
||||
| `recommendations`, `recommendation_evidence` | Recommendation history with evidence |
|
||||
| `risk_evaluations` | Risk evaluation results |
|
||||
| `risk_evaluations`, `risk_configs` | Risk evaluation results and configuration |
|
||||
| `orders`, `order_events` | Order history and lifecycle |
|
||||
| `positions`, `portfolio_snapshots` | Portfolio state |
|
||||
| `global_events`, `macro_impact_records` | Macro event data |
|
||||
@@ -768,6 +800,13 @@ The Query API reads from nearly all tables in the database, including:
|
||||
| `audit_events` | Audit trail |
|
||||
| `market_snapshots` | Market price data |
|
||||
| `watchlists`, `watchlist_members` | Watchlist data |
|
||||
| `ingestion_runs` | Ingestion throughput and source health |
|
||||
| `model_performance_metrics` | Model quality metrics |
|
||||
| `prediction_snapshots`, `prediction_outcomes` | Model validation and calibration |
|
||||
| `trading_decisions` | Trading decision history |
|
||||
| `trading_reports` | Generated daily/weekly reports |
|
||||
| `approval_requests` | Pending approval workflow |
|
||||
| `symbol_lockouts` | Active trading lockouts per symbol |
|
||||
|
||||
### Redis Queues
|
||||
|
||||
@@ -776,15 +815,22 @@ The Query API reads from nearly all tables in the database, including:
|
||||
| Read/Write | `stonks:pipeline:enabled` | Pipeline toggle control |
|
||||
| Read | `stonks:queue:*` | Queue depth monitoring for DLQ and DevOps metrics |
|
||||
| Read | `stonks:dlq:*` | Dead-letter queue inspection and replay |
|
||||
| Read | `stonks:ratelimit:*` | Rate limit status monitoring |
|
||||
|
||||
### Key Behaviors
|
||||
|
||||
- Exposes `/metrics` endpoint for Prometheus scraping
|
||||
- Trace context propagation via `x-trace-id` header middleware
|
||||
- SQL explorer endpoint for ad-hoc Trino queries
|
||||
- SQL explorer endpoint for ad-hoc Trino queries (`/analytics/query`)
|
||||
- PostgreSQL schema explorer (`/pg/schema`, `/pg/query`)
|
||||
- Dead-letter queue management (list, inspect, replay)
|
||||
- Pipeline control (enable/disable via Redis toggle)
|
||||
- Saved queries with CRUD operations
|
||||
- Macro and competitive layer toggle endpoints
|
||||
- Model validation endpoints (summary, calibration, IC by horizon, gate status, attribution)
|
||||
- Trading report listing and retrieval
|
||||
- SSE pipeline health stream (`/pipeline/stream`)
|
||||
- Market price backfill endpoints
|
||||
|
||||
---
|
||||
|
||||
@@ -1042,6 +1088,67 @@ All services load configuration from environment variables via `services/shared/
|
||||
| `OLLAMA_MODEL` | `qwen3.5:9b` | Default model |
|
||||
| `OLLAMA_TIMEOUT` | `120` | Request timeout (seconds) |
|
||||
| `OLLAMA_MAX_RETRIES` | `2` | Max retry attempts |
|
||||
| `OLLAMA_RETRY_BASE_DELAY` | `1.0` | Base delay between retries (seconds) |
|
||||
| `OLLAMA_RETRY_MAX_DELAY` | `10.0` | Maximum delay between retries (seconds) |
|
||||
| `OLLAMA_RETRY_BACKOFF_MULTIPLIER` | `2.0` | Backoff multiplier |
|
||||
|
||||
### vLLM
|
||||
|
||||
| Variable | Default | Description |
|
||||
|---|---|---|
|
||||
| `VLLM_BASE_URL` | `http://192.168.42.254:8000` | vLLM inference server endpoint |
|
||||
| `VLLM_MODEL` | `RedHatAI/Qwen3.6-35B-A3B-NVFP4` | Default vLLM model |
|
||||
| `VLLM_TIMEOUT` | `120` | Request timeout (seconds) |
|
||||
| `VLLM_MAX_RETRIES` | `2` | Max retry attempts |
|
||||
| `VLLM_MAX_TOKENS` | `4096` | Max output tokens |
|
||||
| `VLLM_TEMPERATURE` | `0.7` | Sampling temperature |
|
||||
| `VLLM_API_KEY` | _(empty)_ | Optional API key for authenticated deployments |
|
||||
| `VLLM_RETRY_BASE_DELAY` | `1.0` | Base delay between retries (seconds) |
|
||||
| `VLLM_RETRY_MAX_DELAY` | `10.0` | Maximum delay between retries (seconds) |
|
||||
| `VLLM_RETRY_BACKOFF_MULTIPLIER` | `2.0` | Backoff multiplier |
|
||||
|
||||
### Trino
|
||||
|
||||
| Variable | Default | Description |
|
||||
|---|---|---|
|
||||
| `TRINO_HOST` | `localhost` | Trino host |
|
||||
| `TRINO_PORT` | `8080` | Trino port |
|
||||
| `TRINO_CATALOG` | `lakehouse` | Trino catalog |
|
||||
| `TRINO_SCHEMA` | `stonks` | Trino schema |
|
||||
| `TRINO_ICEBERG_CATALOG` | `iceberg` | Trino Iceberg catalog |
|
||||
|
||||
### Market Data
|
||||
|
||||
| Variable | Default | Description |
|
||||
|---|---|---|
|
||||
| `MARKET_DATA_API_KEY` | _(empty)_ | Polygon.io API key |
|
||||
| `MARKET_DATA_BASE_URL` | `https://api.polygon.io` | Polygon base URL |
|
||||
| `MARKET_DATA_PROVIDER` | `polygon` | Market data provider |
|
||||
|
||||
### Broker
|
||||
|
||||
| Variable | Default | Description |
|
||||
|---|---|---|
|
||||
| `BROKER_MODE` | `paper` | Trading mode (`paper` or `live`) |
|
||||
| `BROKER_PROVIDER` | `alpaca` | Broker provider |
|
||||
| `BROKER_API_KEY` | _(none)_ | Alpaca API key |
|
||||
| `BROKER_API_SECRET` | _(none)_ | Alpaca API secret |
|
||||
| `BROKER_BASE_URL` | _(none)_ | Alpaca base URL |
|
||||
|
||||
### Retention
|
||||
|
||||
| Variable | Default | Description |
|
||||
|---|---|---|
|
||||
| `RETENTION_RAW_MARKET_DAYS` | `90` | Raw market data retention (days) |
|
||||
| `RETENTION_RAW_NEWS_DAYS` | `180` | Raw news data retention (days) |
|
||||
| `RETENTION_RAW_FILINGS_DAYS` | `365` | Raw filings retention (days) |
|
||||
| `RETENTION_NORMALIZED_DAYS` | `180` | Normalized text retention (days) |
|
||||
| `RETENTION_LLM_PROMPTS_DAYS` | `365` | LLM prompt retention (days) |
|
||||
| `RETENTION_LLM_RESULTS_DAYS` | `365` | LLM result retention (days) |
|
||||
| `RETENTION_LAKEHOUSE_DAYS` | `730` | Lakehouse data retention (days) |
|
||||
| `RETENTION_AUDIT_DAYS` | `730` | Audit log retention (days) |
|
||||
| `RETENTION_CLEANUP_INTERVAL_HOURS` | `24` | Cleanup interval (hours) |
|
||||
| `RETENTION_BATCH_SIZE` | `1000` | Rows deleted per batch |
|
||||
|
||||
### Observability
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,3 +1,2 @@
|
||||
node_modules
|
||||
dist
|
||||
.env
|
||||
|
||||
+1
-4
@@ -1,9 +1,6 @@
|
||||
# Stage 1: Build
|
||||
# Base images: uses Harbor proxy cache in CI, falls back to Docker Hub externally
|
||||
# Stage 1: Build (node_modules pre-installed by CI step outside sandbox)
|
||||
FROM registry.celestium.life/dockerhub-cache/library/node:24-alpine AS build
|
||||
WORKDIR /app
|
||||
COPY package.json package-lock.json ./
|
||||
RUN npm ci
|
||||
COPY . .
|
||||
ARG VITE_QUERY_API_URL=""
|
||||
ARG VITE_SYMBOL_REGISTRY_URL=""
|
||||
|
||||
+234
-3
@@ -256,8 +256,13 @@ export interface MarketPrice {
|
||||
captured_at: string;
|
||||
}
|
||||
|
||||
export function useMarketPrices(ticker: string | undefined, limit = 30) {
|
||||
return useGet<MarketPrice[]>(
|
||||
export interface MarketPriceResponse {
|
||||
bars: MarketPrice[];
|
||||
range_90d: { low: number | null; high: number | null };
|
||||
}
|
||||
|
||||
export function useMarketPrices(ticker: string | undefined, limit = 200) {
|
||||
return useGet<MarketPriceResponse>(
|
||||
['market-prices', ticker, limit],
|
||||
'query',
|
||||
`/api/market/prices/${ticker}?limit=${limit}`,
|
||||
@@ -265,6 +270,18 @@ export function useMarketPrices(ticker: string | undefined, limit = 30) {
|
||||
);
|
||||
}
|
||||
|
||||
/** Backfill 90 days of daily bars from Polygon for a single ticker. */
|
||||
export function useBackfillMarketPrices() {
|
||||
const qc = useQueryClient();
|
||||
return useMutation({
|
||||
mutationFn: (ticker: string) =>
|
||||
apiPost<{ ticker: string; inserted: number; total_bars: number }>('query', `/api/market/backfill/${ticker}`, {}),
|
||||
onSuccess: (_data, ticker) => {
|
||||
qc.invalidateQueries({ queryKey: ['market-prices', ticker] });
|
||||
},
|
||||
});
|
||||
}
|
||||
|
||||
export function useTrend(id: string | undefined) {
|
||||
return useGet<TrendSummary>(['trend', id], 'query', `/api/trends/${id}`, !!id);
|
||||
}
|
||||
@@ -372,6 +389,7 @@ export interface Position {
|
||||
quantity: number;
|
||||
avg_entry_price: number;
|
||||
current_price: number | null;
|
||||
polygon_price: number | null;
|
||||
unrealized_pnl: number | null;
|
||||
realized_pnl: number | null;
|
||||
updated_at: string;
|
||||
@@ -662,12 +680,18 @@ export interface CompetitiveSignal {
|
||||
}
|
||||
|
||||
export function useCompetitiveSignals(ticker: string | undefined) {
|
||||
return useGet<CompetitiveSignal[]>(
|
||||
const result = useGet<CompetitiveSignal[] | { competitive_signals: CompetitiveSignal[] }>(
|
||||
['competitive-signals', ticker],
|
||||
'query',
|
||||
`/api/patterns/${ticker}/competitive-signals`,
|
||||
!!ticker,
|
||||
);
|
||||
// API returns { competitive_signals: [...] } wrapper — extract the array
|
||||
const data = result.data;
|
||||
const signals: CompetitiveSignal[] | undefined = data
|
||||
? (Array.isArray(data) ? data : (data as { competitive_signals: CompetitiveSignal[] }).competitive_signals ?? [])
|
||||
: undefined;
|
||||
return { ...result, data: signals };
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
@@ -861,3 +885,210 @@ export function useToggleMacro() {
|
||||
onSuccess: () => qc.invalidateQueries({ queryKey: ['macro-status'] }),
|
||||
});
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Validation: Model Quality & Calibration (Requirements 12.1, 12.2, 12.3, 12.7)
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
export interface ModelMetricSnapshot {
|
||||
id: string;
|
||||
generated_at: string;
|
||||
lookback_window: string;
|
||||
horizon: string;
|
||||
prediction_count: number;
|
||||
win_rate: number | null;
|
||||
directional_accuracy: number | null;
|
||||
information_coefficient: number | null;
|
||||
rank_information_coefficient: number | null;
|
||||
avg_return: number | null;
|
||||
avg_excess_return_vs_spy: number | null;
|
||||
avg_excess_return_vs_sector: number | null;
|
||||
calibration_error: number | null;
|
||||
brier_score: number | null;
|
||||
buy_win_rate: number | null;
|
||||
sell_win_rate: number | null;
|
||||
hold_win_rate: number | null;
|
||||
metadata: Record<string, unknown> | null;
|
||||
}
|
||||
|
||||
export interface ValidationSummary {
|
||||
snapshot: ModelMetricSnapshot | null;
|
||||
gate_status: Record<string, unknown> | null;
|
||||
}
|
||||
|
||||
export interface CalibrationBucket {
|
||||
bucket_low: number;
|
||||
bucket_high: number;
|
||||
avg_confidence: number;
|
||||
observed_win_rate: number;
|
||||
prediction_count: number;
|
||||
miscalibrated: boolean;
|
||||
}
|
||||
|
||||
export interface ValidationCalibration {
|
||||
buckets: CalibrationBucket[];
|
||||
lookback: string;
|
||||
horizon: string;
|
||||
}
|
||||
|
||||
export interface ICByHorizonEntry {
|
||||
horizon: string;
|
||||
information_coefficient: number | null;
|
||||
rank_information_coefficient: number | null;
|
||||
prediction_count: number;
|
||||
generated_at: string | null;
|
||||
}
|
||||
|
||||
export interface ValidationICByHorizon {
|
||||
horizons: ICByHorizonEntry[];
|
||||
lookback: string;
|
||||
}
|
||||
|
||||
export interface ValidationGateStatus {
|
||||
gate_status: Record<string, unknown> | null;
|
||||
updated_at?: string | null;
|
||||
message?: string;
|
||||
}
|
||||
|
||||
export function useValidationSummary(lookback = '30d', horizon = '7d') {
|
||||
const qs = new URLSearchParams();
|
||||
if (lookback) qs.set('lookback', lookback);
|
||||
if (horizon) qs.set('horizon', horizon);
|
||||
const path = `/api/validation/summary${qs.toString() ? '?' + qs : ''}`;
|
||||
return useGet<ValidationSummary>(['validation-summary', lookback, horizon], 'query', path);
|
||||
}
|
||||
|
||||
export function useValidationCalibration(lookback = '30d', horizon = '7d') {
|
||||
const qs = new URLSearchParams();
|
||||
if (lookback) qs.set('lookback', lookback);
|
||||
if (horizon) qs.set('horizon', horizon);
|
||||
const path = `/api/validation/calibration${qs.toString() ? '?' + qs : ''}`;
|
||||
return useGet<ValidationCalibration>(['validation-calibration', lookback, horizon], 'query', path);
|
||||
}
|
||||
|
||||
export function useValidationICByHorizon(lookback = '30d') {
|
||||
const qs = new URLSearchParams();
|
||||
if (lookback) qs.set('lookback', lookback);
|
||||
const path = `/api/validation/ic-by-horizon${qs.toString() ? '?' + qs : ''}`;
|
||||
return useGet<ValidationICByHorizon>(['validation-ic-by-horizon', lookback], 'query', path);
|
||||
}
|
||||
|
||||
export function useValidationGateStatus() {
|
||||
return useGet<ValidationGateStatus>(['validation-gate-status'], 'query', '/api/validation/gate-status');
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Validation: Attribution — Sources, Catalysts, Layers (Requirements 12.4, 12.5, 12.6)
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
export interface SourceAttribution {
|
||||
source: string;
|
||||
source_type: string;
|
||||
prediction_count: number;
|
||||
avg_weight: number;
|
||||
avg_contribution_score: number;
|
||||
win_rate: number;
|
||||
avg_future_return: number;
|
||||
avg_excess_return_vs_spy: number;
|
||||
information_coefficient: number | null;
|
||||
duplicate_rate: number;
|
||||
}
|
||||
|
||||
export interface SourceAttributionResponse {
|
||||
sources: SourceAttribution[];
|
||||
lookback: string;
|
||||
horizon: string;
|
||||
}
|
||||
|
||||
export interface CatalystAttribution {
|
||||
catalyst_type: string;
|
||||
prediction_count: number;
|
||||
win_rate: number;
|
||||
avg_future_return: number;
|
||||
avg_excess_return_vs_spy: number;
|
||||
information_coefficient: number | null;
|
||||
}
|
||||
|
||||
export interface CatalystAttributionResponse {
|
||||
catalysts: CatalystAttribution[];
|
||||
lookback: string;
|
||||
horizon: string;
|
||||
}
|
||||
|
||||
export interface LayerAttribution {
|
||||
layer: string;
|
||||
avg_contribution_pct: number;
|
||||
dominant_win_rate: number;
|
||||
dominant_ic: number | null;
|
||||
}
|
||||
|
||||
export interface LayerAttributionResponse {
|
||||
layers: LayerAttribution[];
|
||||
lookback: string;
|
||||
horizon: string;
|
||||
}
|
||||
|
||||
export function useValidationAttributionSources(lookback = '30d', horizon = '7d') {
|
||||
const qs = new URLSearchParams();
|
||||
if (lookback) qs.set('lookback', lookback);
|
||||
if (horizon) qs.set('horizon', horizon);
|
||||
const path = `/api/validation/attribution/sources${qs.toString() ? '?' + qs : ''}`;
|
||||
return useGet<SourceAttributionResponse>(['validation-attribution-sources', lookback, horizon], 'query', path);
|
||||
}
|
||||
|
||||
export function useValidationAttributionCatalysts(lookback = '30d', horizon = '7d') {
|
||||
const qs = new URLSearchParams();
|
||||
if (lookback) qs.set('lookback', lookback);
|
||||
if (horizon) qs.set('horizon', horizon);
|
||||
const path = `/api/validation/attribution/catalysts${qs.toString() ? '?' + qs : ''}`;
|
||||
return useGet<CatalystAttributionResponse>(['validation-attribution-catalysts', lookback, horizon], 'query', path);
|
||||
}
|
||||
|
||||
export function useValidationAttributionLayers(lookback = '30d', horizon = '7d') {
|
||||
const qs = new URLSearchParams();
|
||||
if (lookback) qs.set('lookback', lookback);
|
||||
if (horizon) qs.set('horizon', horizon);
|
||||
const path = `/api/validation/attribution/layers${qs.toString() ? '?' + qs : ''}`;
|
||||
return useGet<LayerAttributionResponse>(['validation-attribution-layers', lookback, horizon], 'query', path);
|
||||
}
|
||||
|
||||
// ---------------------------------------------------------------------------
|
||||
// Trading Reports
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
export interface ReportListItem {
|
||||
id: string;
|
||||
report_type: string;
|
||||
period_start: string;
|
||||
period_end: string;
|
||||
validation_status: string;
|
||||
generated_at: string;
|
||||
}
|
||||
|
||||
export interface ReportDetail extends ReportListItem {
|
||||
report_data: Record<string, unknown>;
|
||||
created_at: string;
|
||||
}
|
||||
|
||||
export function useReports(params?: {
|
||||
report_type?: string;
|
||||
start_date?: string;
|
||||
end_date?: string;
|
||||
limit?: number;
|
||||
offset?: number;
|
||||
}) {
|
||||
const qs = new URLSearchParams();
|
||||
if (params?.report_type) qs.set('report_type', params.report_type);
|
||||
if (params?.start_date) qs.set('start_date', params.start_date);
|
||||
if (params?.end_date) qs.set('end_date', params.end_date);
|
||||
if (params?.limit) qs.set('limit', String(params.limit));
|
||||
if (params?.offset) qs.set('offset', String(params.offset));
|
||||
const path = `/api/reports${qs.toString() ? '?' + qs : ''}`;
|
||||
return useGet<ReportListItem[]>(['reports', params], 'query', path);
|
||||
}
|
||||
|
||||
export function useReport(id: string | undefined) {
|
||||
return useGet<ReportDetail>(
|
||||
['report', id], 'query', `/api/reports/${id}`, !!id
|
||||
);
|
||||
}
|
||||
|
||||
@@ -22,6 +22,8 @@ export interface TradingEngineStatus {
|
||||
portfolio_heat: number;
|
||||
portfolio_value: number;
|
||||
open_position_count: number;
|
||||
max_open_positions: number;
|
||||
absolute_position_cap: number;
|
||||
last_decision_at: string | null;
|
||||
micro_trading_enabled: boolean;
|
||||
uptime_seconds: number | null;
|
||||
@@ -314,9 +316,12 @@ export function useBacktestLaunch() {
|
||||
export function useResetPaperTrading() {
|
||||
const qc = useQueryClient();
|
||||
return useMutation({
|
||||
mutationFn: (initial_capital: number = 0) =>
|
||||
mutationFn: (params: { initial_capital?: number; reserve_pct?: number } = {}) =>
|
||||
apiPost<{ reset: boolean; initial_capital: number; active_pool: number; reserve_pool: number; broker: Record<string, number> }>(
|
||||
'trading', '/api/trading/reset', { initial_capital },
|
||||
'trading', '/api/trading/reset', {
|
||||
initial_capital: params.initial_capital ?? 0,
|
||||
reserve_pct: params.reserve_pct ?? undefined,
|
||||
},
|
||||
),
|
||||
onSuccess: () => {
|
||||
qc.invalidateQueries({ queryKey: ['trading-status'] });
|
||||
|
||||
@@ -19,6 +19,7 @@ import {
|
||||
Globe,
|
||||
BarChart3,
|
||||
Bot,
|
||||
ClipboardList,
|
||||
} from 'lucide-react';
|
||||
|
||||
interface NavItem {
|
||||
@@ -40,6 +41,7 @@ const navItems: NavItem[] = [
|
||||
{ to: '/positions', label: 'Positions', icon: <Wallet size={18} />, group: 'Trading' },
|
||||
{ to: '/trading', label: 'Trading Controls', icon: <ShieldCheck size={18} />, group: 'Trading' },
|
||||
{ to: '/trading/engine', label: 'Trading Engine', icon: <BarChart3 size={18} />, group: 'Trading' },
|
||||
{ to: '/reports', label: 'Reports', icon: <ClipboardList size={18} />, group: 'Trading' },
|
||||
{ to: '/ops/pipeline', label: 'Pipeline', icon: <Activity size={18} />, group: 'Ops' },
|
||||
{ to: '/ops/ingestion', label: 'Ingestion', icon: <Download size={18} />, group: 'Ops' },
|
||||
{ to: '/ops/model', label: 'Model Perf', icon: <Cpu size={18} />, group: 'Ops' },
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
import { useParams, useNavigate } from '@tanstack/react-router';
|
||||
import { useState } from 'react';
|
||||
import { useParams, useNavigate, Link } from '@tanstack/react-router';
|
||||
import { useState, useEffect } from 'react';
|
||||
import {
|
||||
useCompany,
|
||||
useCompanySources,
|
||||
@@ -14,13 +14,15 @@ import {
|
||||
useTrends,
|
||||
useTrendHistory,
|
||||
useMarketPrices,
|
||||
useDocument,
|
||||
usePositions,
|
||||
} from '../api/hooks';
|
||||
import { StatusBadge, ConfidenceBar, LoadingSpinner, Card } from '../components/ui';
|
||||
import { DataTable, type Column } from '../components/DataTable';
|
||||
import type { Source, Alias, MacroImpactRecord, CompetitorRelationship, HistoricalPattern, CompetitiveSignal, CorporateDecision, TrendSummary, MarketPrice } from '../api/hooks';
|
||||
import {
|
||||
LineChart, Line, XAxis, YAxis, Tooltip, ResponsiveContainer,
|
||||
CartesianGrid, Legend,
|
||||
CartesianGrid, Legend, ReferenceLine,
|
||||
} from 'recharts';
|
||||
|
||||
const sourceCols: Column<Source>[] = [
|
||||
@@ -42,8 +44,12 @@ export function CompanyDetailPage() {
|
||||
const { data: signals } = useCompetitiveSignals(company?.ticker);
|
||||
const { data: decisions } = useCorporateDecisions(company?.ticker);
|
||||
const { data: trends } = useTrends({ ticker: company?.ticker, limit: 200 });
|
||||
const { data: trendHistory } = useTrendHistory({ ticker: company?.ticker, limit: 500 });
|
||||
const { data: marketPrices } = useMarketPrices(company?.ticker, 200);
|
||||
const [selectedWindow, setSelectedWindow] = useState('7d');
|
||||
const { data: trendHistory } = useTrendHistory({ ticker: company?.ticker, window: selectedWindow, limit: 500 });
|
||||
const { data: marketPriceData } = useMarketPrices(company?.ticker, 200);
|
||||
const marketPrices = marketPriceData?.bars ?? [];
|
||||
const range90d = marketPriceData?.range_90d ?? { low: null, high: null };
|
||||
const { data: positions } = usePositions(company?.ticker);
|
||||
const [tab, setTab] = useState<'trends' | 'sources' | 'aliases' | 'macro' | 'competitors' | 'patterns' | 'signals' | 'decisions'>('trends');
|
||||
|
||||
if (isLoading || !company) return <LoadingSpinner />;
|
||||
@@ -82,7 +88,10 @@ export function CompanyDetailPage() {
|
||||
</div>
|
||||
|
||||
{tab === 'trends' && (
|
||||
<TrendHistoryChart trends={trendHistory ?? []} latestTrends={trends ?? []} ticker={company.ticker} marketPrices={marketPrices ?? []} />
|
||||
<div className="space-y-4">
|
||||
<PositionCard positions={positions ?? []} ticker={company.ticker} />
|
||||
<TrendHistoryChart trends={trendHistory ?? []} latestTrends={trends ?? []} ticker={company.ticker} marketPrices={marketPrices} range90d={range90d} selectedWindow={selectedWindow} onWindowChange={setSelectedWindow} />
|
||||
</div>
|
||||
)}
|
||||
|
||||
{tab === 'sources' && (
|
||||
@@ -444,62 +453,7 @@ function CompetitiveSignalsPanel({ signals }: { signals: CompetitiveSignal[] })
|
||||
) : (
|
||||
<div className="space-y-2">
|
||||
{signals.map((s) => (
|
||||
<div key={s.id}>
|
||||
<div
|
||||
className="flex items-center justify-between rounded-lg border border-cyan-700/30 bg-cyan-900/10 p-3 cursor-pointer hover:border-cyan-500/50"
|
||||
onClick={() => setExpandedId(expandedId === s.id ? null : s.id)}
|
||||
>
|
||||
<div className="flex items-center gap-3">
|
||||
<span className="rounded bg-cyan-900/40 border border-cyan-700/50 px-1.5 py-0.5 text-[10px] font-medium text-cyan-400">COMPETITIVE</span>
|
||||
<span className="font-mono text-sm text-brand-300">{s.source_ticker}</span>
|
||||
<span className="text-xs text-gray-400">→</span>
|
||||
<StatusBadge status={s.catalyst_type} />
|
||||
<StatusBadge status={s.signal_direction} />
|
||||
</div>
|
||||
<div className="flex items-center gap-3">
|
||||
<ConfidenceBar value={s.signal_strength} />
|
||||
<span className="text-xs text-gray-500">{new Date(s.computed_at).toLocaleDateString()}</span>
|
||||
</div>
|
||||
</div>
|
||||
{expandedId === s.id && (
|
||||
<Card className="mt-1 ml-4">
|
||||
<dl className="grid grid-cols-2 gap-x-6 gap-y-2 text-xs sm:grid-cols-3">
|
||||
<div>
|
||||
<dt className="text-gray-500">Source Ticker</dt>
|
||||
<dd className="font-mono text-gray-200">{s.source_ticker}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Target Ticker</dt>
|
||||
<dd className="font-mono text-gray-200">{s.target_ticker}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Catalyst Type</dt>
|
||||
<dd className="text-gray-200">{s.catalyst_type}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Pattern Confidence</dt>
|
||||
<dd><ConfidenceBar value={s.pattern_confidence} /></dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Signal Strength</dt>
|
||||
<dd><ConfidenceBar value={s.signal_strength} /></dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Relationship Strength</dt>
|
||||
<dd><ConfidenceBar value={s.relationship_strength} /></dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Source Document</dt>
|
||||
<dd className="font-mono text-gray-400 text-[10px]">{s.source_document_id}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Computed At</dt>
|
||||
<dd className="text-gray-200">{new Date(s.computed_at).toLocaleString()}</dd>
|
||||
</div>
|
||||
</dl>
|
||||
</Card>
|
||||
)}
|
||||
</div>
|
||||
<SignalRow key={s.id} signal={s} expanded={expandedId === s.id} onToggle={() => setExpandedId(expandedId === s.id ? null : s.id)} />
|
||||
))}
|
||||
</div>
|
||||
)}
|
||||
@@ -507,6 +461,88 @@ function CompetitiveSignalsPanel({ signals }: { signals: CompetitiveSignal[] })
|
||||
);
|
||||
}
|
||||
|
||||
function SignalRow({ signal: s, expanded, onToggle }: { signal: CompetitiveSignal; expanded: boolean; onToggle: () => void }) {
|
||||
const { data: doc } = useDocument(s.source_document_id);
|
||||
const docLabel = doc?.title ?? `doc:${s.source_document_id.slice(0, 8)}…`;
|
||||
|
||||
return (
|
||||
<div>
|
||||
<div
|
||||
className="flex items-center justify-between rounded-lg border border-cyan-700/30 bg-cyan-900/10 p-3 cursor-pointer hover:border-cyan-500/50"
|
||||
onClick={onToggle}
|
||||
>
|
||||
<div className="flex items-center gap-3">
|
||||
<span className="rounded bg-cyan-900/40 border border-cyan-700/50 px-1.5 py-0.5 text-[10px] font-medium text-cyan-400">COMPETITIVE</span>
|
||||
<span className="font-mono text-sm text-brand-300">{s.source_ticker}</span>
|
||||
<span className="text-xs text-gray-400">→</span>
|
||||
<StatusBadge status={s.catalyst_type} />
|
||||
<StatusBadge status={s.signal_direction} />
|
||||
</div>
|
||||
<div className="flex items-center gap-3">
|
||||
<Link
|
||||
to="/documents/$id"
|
||||
params={{ id: s.source_document_id }}
|
||||
className="max-w-[180px] truncate text-xs text-brand-400 hover:underline"
|
||||
onClick={(e) => e.stopPropagation()}
|
||||
title={doc?.title ?? s.source_document_id}
|
||||
>
|
||||
{docLabel}
|
||||
</Link>
|
||||
<ConfidenceBar value={s.signal_strength} />
|
||||
<span className="text-xs text-gray-500">{new Date(s.computed_at).toLocaleDateString()}</span>
|
||||
</div>
|
||||
</div>
|
||||
{expanded && (
|
||||
<Card className="mt-1 ml-4">
|
||||
<dl className="grid grid-cols-2 gap-x-6 gap-y-2 text-xs sm:grid-cols-3">
|
||||
<div>
|
||||
<dt className="text-gray-500">Source Ticker</dt>
|
||||
<dd className="font-mono text-gray-200">{s.source_ticker}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Target Ticker</dt>
|
||||
<dd className="font-mono text-gray-200">{s.target_ticker}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Catalyst Type</dt>
|
||||
<dd className="text-gray-200">{s.catalyst_type}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Pattern Confidence</dt>
|
||||
<dd><ConfidenceBar value={s.pattern_confidence} /></dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Signal Strength</dt>
|
||||
<dd><ConfidenceBar value={s.signal_strength} /></dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Relationship Strength</dt>
|
||||
<dd><ConfidenceBar value={s.relationship_strength} /></dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Source Document</dt>
|
||||
<dd>
|
||||
<Link
|
||||
to="/documents/$id"
|
||||
params={{ id: s.source_document_id }}
|
||||
className="text-brand-400 hover:underline"
|
||||
onClick={(e) => e.stopPropagation()}
|
||||
>
|
||||
{docLabel}
|
||||
</Link>
|
||||
</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Computed At</dt>
|
||||
<dd className="text-gray-200">{new Date(s.computed_at).toLocaleString()}</dd>
|
||||
</div>
|
||||
</dl>
|
||||
</Card>
|
||||
)}
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function DecisionsPanel({ decisions }: { decisions: CorporateDecision[] }) {
|
||||
return (
|
||||
<div className="space-y-4">
|
||||
@@ -568,13 +604,30 @@ interface ChartPoint {
|
||||
price?: number;
|
||||
}
|
||||
|
||||
function ChartXTick({ x, y, payload }: { x?: number; y?: number; payload?: { value: number } }) {
|
||||
if (!payload || !x || !y) return null;
|
||||
const d = new Date(payload.value);
|
||||
const dateStr = d.toLocaleDateString('en-US', { month: 'short', day: 'numeric' });
|
||||
const timeStr = d.toLocaleTimeString('en-US', { hour: 'numeric', hour12: true });
|
||||
|
||||
return (
|
||||
<g transform={`translate(${x},${y + 4})`}>
|
||||
<text x={0} y={0} textAnchor="end" fontSize={10} transform="rotate(-35)">
|
||||
<tspan fill="#e2e8f0" fontWeight="bold">{dateStr} </tspan>
|
||||
<tspan fill="#94a3b8">{timeStr}</tspan>
|
||||
</text>
|
||||
</g>
|
||||
);
|
||||
}
|
||||
|
||||
function TrendTooltip({ active, payload, label }: Record<string, unknown>) {
|
||||
if (!active) return null;
|
||||
const items = payload as Array<{ name: string; value: number; color: string; dataKey: string }> | undefined;
|
||||
if (!items?.length) return null;
|
||||
const ts = typeof label === 'number' ? new Date(label).toLocaleString('en-US', { month: 'short', day: 'numeric', hour: 'numeric', minute: '2-digit' }) : String(label ?? '');
|
||||
return (
|
||||
<div className="rounded-lg border border-surface-700 bg-surface-900 px-3 py-2 text-xs shadow-lg">
|
||||
<div className="mb-1 text-gray-400">{String(label ?? '')}</div>
|
||||
<div className="mb-1 text-gray-400">{ts}</div>
|
||||
{items.map((item, i) => (
|
||||
<div key={i} className="flex justify-between gap-4" style={{ color: item.color }}>
|
||||
<span>{item.name}:</span>
|
||||
@@ -587,12 +640,64 @@ function TrendTooltip({ active, payload, label }: Record<string, unknown>) {
|
||||
);
|
||||
}
|
||||
|
||||
function TrendHistoryChart({ trends, latestTrends, ticker, marketPrices }: { trends: TrendSummary[]; latestTrends: TrendSummary[]; ticker: string; marketPrices: MarketPrice[] }) {
|
||||
const [selectedWindow, setSelectedWindow] = useState('7d');
|
||||
function PositionCard({ positions, ticker }: { positions: import('../api/hooks').Position[]; ticker: string }) {
|
||||
const pos = positions.find((p) => p.ticker === ticker && p.quantity > 0);
|
||||
if (!pos) return null;
|
||||
|
||||
// Use history data for charts
|
||||
const marketValue = pos.current_price ? pos.quantity * pos.current_price : null;
|
||||
const pnlColor = (pos.unrealized_pnl ?? 0) >= 0 ? 'text-green-400' : 'text-red-400';
|
||||
const pnlSign = (pos.unrealized_pnl ?? 0) >= 0 ? '+' : '';
|
||||
|
||||
return (
|
||||
<Card>
|
||||
<div className="flex items-center justify-between">
|
||||
<h2 className="text-sm font-medium text-gray-400">Open Position</h2>
|
||||
<StatusBadge status="active" />
|
||||
</div>
|
||||
<dl className="mt-2 grid grid-cols-2 gap-x-8 gap-y-2 text-sm sm:grid-cols-5">
|
||||
<div>
|
||||
<dt className="text-gray-500">Shares</dt>
|
||||
<dd className="font-mono text-gray-200">{pos.quantity}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Avg Entry</dt>
|
||||
<dd className="font-mono text-gray-200">${pos.avg_entry_price.toFixed(2)}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Current Price</dt>
|
||||
<dd className="font-mono text-gray-200">{pos.current_price ? `$${pos.current_price.toFixed(2)}` : '—'}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Market Value</dt>
|
||||
<dd className="font-mono text-gray-200">{marketValue ? `$${marketValue.toLocaleString(undefined, { minimumFractionDigits: 2, maximumFractionDigits: 2 })}` : '—'}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Unrealized P&L</dt>
|
||||
<dd className={`font-mono font-semibold ${pnlColor}`}>
|
||||
{pos.unrealized_pnl != null ? `${pnlSign}$${Math.abs(pos.unrealized_pnl).toFixed(2)}` : '—'}
|
||||
</dd>
|
||||
</div>
|
||||
</dl>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
function TrendHistoryChart({ trends, latestTrends, ticker, marketPrices, range90d, selectedWindow, onWindowChange }: { trends: TrendSummary[]; latestTrends: TrendSummary[]; ticker: string; marketPrices: MarketPrice[]; range90d: { low: number | null; high: number | null }; selectedWindow: string; onWindowChange: (w: string) => void }) {
|
||||
|
||||
// Determine the time range for the selected window to filter data
|
||||
const windowHours: Record<string, number> = {
|
||||
intraday: 24,
|
||||
'1d': 48,
|
||||
'7d': 7 * 24,
|
||||
'30d': 30 * 24,
|
||||
'90d': 90 * 24,
|
||||
};
|
||||
const hoursBack = windowHours[selectedWindow] ?? 7 * 24;
|
||||
const cutoffTs = Date.now() - hoursBack * 3600_000;
|
||||
|
||||
// Use history data for charts — filter to selected window and time range
|
||||
const filtered = (trends ?? [])
|
||||
.filter((t) => t.entity_id === ticker && t.window === selectedWindow)
|
||||
.filter((t) => t.entity_id === ticker && t.window === selectedWindow && new Date(t.generated_at).getTime() >= cutoffTs)
|
||||
.sort((a, b) => new Date(a.generated_at).getTime() - new Date(b.generated_at).getTime());
|
||||
|
||||
// Build a price lookup — match by closest timestamp to each trend point
|
||||
@@ -600,19 +705,30 @@ function TrendHistoryChart({ trends, latestTrends, ticker, marketPrices }: { tre
|
||||
.filter((p) => p.bar_timestamp != null && p.close != null)
|
||||
.sort((a, b) => a.bar_timestamp - b.bar_timestamp);
|
||||
|
||||
// Filter prices to the selected window's time range (use all prices if sparse)
|
||||
const windowPrices = sortedPrices.length <= 20 ? sortedPrices : sortedPrices.filter((p) => p.bar_timestamp >= cutoffTs);
|
||||
|
||||
function findClosestPrice(ts: number): number | undefined {
|
||||
if (sortedPrices.length === 0) return undefined;
|
||||
let best = sortedPrices[0];
|
||||
if (windowPrices.length === 0) return undefined;
|
||||
let best = windowPrices[0];
|
||||
let bestDiff = Math.abs(ts - best.bar_timestamp);
|
||||
for (const p of sortedPrices) {
|
||||
for (const p of windowPrices) {
|
||||
const diff = Math.abs(ts - p.bar_timestamp);
|
||||
if (diff < bestDiff) {
|
||||
best = p;
|
||||
bestDiff = diff;
|
||||
}
|
||||
}
|
||||
// Only match if within 2 hours (for intraday) or 36 hours (for daily)
|
||||
const maxGap = selectedWindow === 'intraday' ? 2 * 3600_000 : 36 * 3600_000;
|
||||
// Match if within reasonable gap for the window type
|
||||
// With sparse price data (~1 bar per 4-6 hours), use wider tolerances
|
||||
const maxGapHours: Record<string, number> = {
|
||||
intraday: 6,
|
||||
'1d': 12,
|
||||
'7d': 36,
|
||||
'30d': 72,
|
||||
'90d': 168,
|
||||
};
|
||||
const maxGap = (maxGapHours[selectedWindow] ?? 36) * 3600_000;
|
||||
return bestDiff <= maxGap ? best.close : undefined;
|
||||
}
|
||||
|
||||
@@ -620,7 +736,7 @@ function TrendHistoryChart({ trends, latestTrends, ticker, marketPrices }: { tre
|
||||
const trendTs = new Date(t.generated_at).getTime();
|
||||
const price = findClosestPrice(trendTs);
|
||||
return {
|
||||
time: new Date(t.generated_at).toLocaleDateString('en-US', { month: 'short', day: 'numeric', hour: '2-digit', minute: '2-digit' }),
|
||||
time: String(trendTs),
|
||||
timestamp: trendTs,
|
||||
strength: +(t.trend_strength * 100).toFixed(1),
|
||||
confidence: +(t.confidence * 100).toFixed(1),
|
||||
@@ -634,6 +750,34 @@ function TrendHistoryChart({ trends, latestTrends, ticker, marketPrices }: { tre
|
||||
|
||||
const hasPrice = chartData.some((pt) => pt.price != null);
|
||||
|
||||
// Compute market open/close vertical markers for intraday and 1d windows
|
||||
const showMarketMarkers = selectedWindow === 'intraday' || selectedWindow === '1d';
|
||||
const marketMarkers: { ts: number; label: string }[] = [];
|
||||
if (showMarketMarkers && chartData.length > 0) {
|
||||
const minTs = chartData[0].timestamp;
|
||||
const maxTs = chartData[chartData.length - 1].timestamp;
|
||||
// Walk each day in the range and compute 9:30 AM ET (open) and 4:00 PM ET (close)
|
||||
const dayMs = 86400_000;
|
||||
const startDay = new Date(minTs);
|
||||
startDay.setUTCHours(0, 0, 0, 0);
|
||||
for (let d = startDay.getTime(); d <= maxTs + dayMs; d += dayMs) {
|
||||
const date = new Date(d);
|
||||
const dow = date.getUTCDay();
|
||||
if (dow === 0 || dow === 6) continue; // skip weekends
|
||||
// ET offset: EDT = UTC-4, EST = UTC-5. Approximate with -4 (summer).
|
||||
// 9:30 AM ET = 13:30 UTC (EDT)
|
||||
const openTs = d + 13 * 3600_000 + 30 * 60_000;
|
||||
// 4:00 PM ET = 20:00 UTC (EDT)
|
||||
const closeTs = d + 20 * 3600_000;
|
||||
if (openTs >= minTs && openTs <= maxTs) {
|
||||
marketMarkers.push({ ts: openTs, label: 'Open' });
|
||||
}
|
||||
if (closeTs >= minTs && closeTs <= maxTs) {
|
||||
marketMarkers.push({ ts: closeTs, label: 'Close' });
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Available windows from the data (check both history and latest)
|
||||
const allTrends = [...(trends ?? []), ...(latestTrends ?? [])];
|
||||
const availableWindows = [...new Set(allTrends.filter((t) => t.entity_id === ticker).map((t) => t.window))];
|
||||
@@ -645,6 +789,94 @@ function TrendHistoryChart({ trends, latestTrends, ticker, marketPrices }: { tre
|
||||
.sort((a, b) => new Date(b.generated_at).getTime() - new Date(a.generated_at).getTime());
|
||||
const latest = latestForWindow[0] ?? (filtered.length > 0 ? filtered[filtered.length - 1] : null);
|
||||
|
||||
const [fullscreen, setFullscreen] = useState(false);
|
||||
|
||||
// Close fullscreen on Escape key
|
||||
useEffect(() => {
|
||||
if (!fullscreen) return;
|
||||
const handler = (e: KeyboardEvent) => { if (e.key === 'Escape') setFullscreen(false); };
|
||||
window.addEventListener('keydown', handler);
|
||||
return () => window.removeEventListener('keydown', handler);
|
||||
}, [fullscreen]);
|
||||
|
||||
// Shared chart content — rendered at different sizes
|
||||
const chartContent = (height: number) => (
|
||||
<ResponsiveContainer width="100%" height={height}>
|
||||
<LineChart data={chartData} margin={{ top: 5, right: 20, bottom: 70, left: 0 }}>
|
||||
<CartesianGrid strokeDasharray="3 3" stroke="#334155" />
|
||||
{marketMarkers.map((m, i) => (
|
||||
<ReferenceLine
|
||||
key={`market-${i}`}
|
||||
yAxisId="left"
|
||||
x={m.ts}
|
||||
stroke={m.label === 'Open' ? '#22c55e' : '#ef4444'}
|
||||
strokeDasharray="4 4"
|
||||
strokeWidth={1}
|
||||
strokeOpacity={0.5}
|
||||
label={{ value: m.label, position: 'top', fill: m.label === 'Open' ? '#22c55e' : '#ef4444', fontSize: 9 }}
|
||||
/>
|
||||
))}
|
||||
<XAxis
|
||||
dataKey="timestamp"
|
||||
type="number"
|
||||
domain={['dataMin', 'dataMax']}
|
||||
scale="time"
|
||||
tick={<ChartXTick />}
|
||||
tickLine={{ stroke: '#475569' }}
|
||||
tickCount={8}
|
||||
/>
|
||||
<YAxis
|
||||
yAxisId="left"
|
||||
domain={[0, 100]}
|
||||
tick={{ fill: '#94a3b8', fontSize: 11 }}
|
||||
tickLine={{ stroke: '#475569' }}
|
||||
tickFormatter={(v) => `${v}%`}
|
||||
/>
|
||||
{hasPrice && (
|
||||
<YAxis
|
||||
yAxisId="right"
|
||||
orientation="right"
|
||||
tick={{ fill: '#e879f9', fontSize: 11 }}
|
||||
tickLine={{ stroke: '#475569' }}
|
||||
tickFormatter={(v) => `$${v}`}
|
||||
domain={[
|
||||
range90d.low != null ? Math.floor(range90d.low * 0.97) : 'dataMin - 2',
|
||||
range90d.high != null ? Math.ceil(range90d.high * 1.03) : 'dataMax + 2',
|
||||
]}
|
||||
/>
|
||||
)}
|
||||
<Tooltip content={TrendTooltip} />
|
||||
<Legend verticalAlign="bottom" wrapperStyle={{ color: '#94a3b8', fontSize: 12, paddingTop: 24 }} />
|
||||
{hasPrice && range90d.high != null && (
|
||||
<ReferenceLine
|
||||
yAxisId="right"
|
||||
y={range90d.high}
|
||||
stroke="#22c55e"
|
||||
strokeDasharray="6 3"
|
||||
strokeWidth={1.5}
|
||||
label={{ value: `90d High $${range90d.high.toFixed(2)}`, position: 'insideTopRight', fill: '#22c55e', fontSize: 10 }}
|
||||
/>
|
||||
)}
|
||||
{hasPrice && range90d.low != null && (
|
||||
<ReferenceLine
|
||||
yAxisId="right"
|
||||
y={range90d.low}
|
||||
stroke="#ef4444"
|
||||
strokeDasharray="6 3"
|
||||
strokeWidth={1.5}
|
||||
label={{ value: `90d Low $${range90d.low.toFixed(2)}`, position: 'insideBottomRight', fill: '#ef4444', fontSize: 10 }}
|
||||
/>
|
||||
)}
|
||||
<Line yAxisId="left" type="monotone" dataKey="strength" name="Trend Strength" stroke="#3b82f6" strokeWidth={2} dot={{ r: 3, fill: '#3b82f6' }} activeDot={{ r: 5 }} />
|
||||
<Line yAxisId="left" type="monotone" dataKey="confidence" name="Confidence" stroke="#10b981" strokeWidth={2} dot={{ r: 3, fill: '#10b981' }} activeDot={{ r: 5 }} />
|
||||
<Line yAxisId="left" type="monotone" dataKey="contradiction" name="Contradiction" stroke="#f59e0b" strokeWidth={1.5} strokeDasharray="5 5" dot={{ r: 2, fill: '#f59e0b' }} />
|
||||
{hasPrice && (
|
||||
<Line yAxisId="right" type="monotone" dataKey="price" name="Price" stroke="#e879f9" strokeWidth={2} dot={{ r: 3, fill: '#e879f9' }} activeDot={{ r: 5 }} connectNulls />
|
||||
)}
|
||||
</LineChart>
|
||||
</ResponsiveContainer>
|
||||
);
|
||||
|
||||
return (
|
||||
<div className="space-y-4">
|
||||
{/* Window selector */}
|
||||
@@ -653,7 +885,7 @@ function TrendHistoryChart({ trends, latestTrends, ticker, marketPrices }: { tre
|
||||
{(availableWindows.length > 0 ? availableWindows : WINDOW_ORDER).map((w) => (
|
||||
<button
|
||||
key={w}
|
||||
onClick={() => setSelectedWindow(w)}
|
||||
onClick={() => onWindowChange(w)}
|
||||
className={`rounded-md px-3 py-1 text-xs font-medium transition-colors ${
|
||||
selectedWindow === w
|
||||
? 'bg-brand-600 text-white'
|
||||
@@ -673,83 +905,47 @@ function TrendHistoryChart({ trends, latestTrends, ticker, marketPrices }: { tre
|
||||
<>
|
||||
{/* Trend Strength & Confidence Chart */}
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">
|
||||
Trend Strength & Confidence — {ticker} / {selectedWindow}
|
||||
</h2>
|
||||
<ResponsiveContainer width="100%" height={280}>
|
||||
<LineChart data={chartData} margin={{ top: 5, right: 20, bottom: 5, left: 0 }}>
|
||||
<CartesianGrid strokeDasharray="3 3" stroke="#334155" />
|
||||
<XAxis
|
||||
dataKey="time"
|
||||
tick={{ fill: '#94a3b8', fontSize: 11 }}
|
||||
tickLine={{ stroke: '#475569' }}
|
||||
/>
|
||||
<YAxis
|
||||
yAxisId="left"
|
||||
domain={[0, 100]}
|
||||
tick={{ fill: '#94a3b8', fontSize: 11 }}
|
||||
tickLine={{ stroke: '#475569' }}
|
||||
tickFormatter={(v) => `${v}%`}
|
||||
/>
|
||||
{hasPrice && (
|
||||
<YAxis
|
||||
yAxisId="right"
|
||||
orientation="right"
|
||||
tick={{ fill: '#e879f9', fontSize: 11 }}
|
||||
tickLine={{ stroke: '#475569' }}
|
||||
tickFormatter={(v) => `$${v}`}
|
||||
domain={['dataMin - 2', 'dataMax + 2']}
|
||||
/>
|
||||
)}
|
||||
<Tooltip content={TrendTooltip} />
|
||||
<Legend wrapperStyle={{ color: '#94a3b8', fontSize: 12 }} />
|
||||
<Line
|
||||
yAxisId="left"
|
||||
type="monotone"
|
||||
dataKey="strength"
|
||||
name="Trend Strength"
|
||||
stroke="#3b82f6"
|
||||
strokeWidth={2}
|
||||
dot={{ r: 3, fill: '#3b82f6' }}
|
||||
activeDot={{ r: 5 }}
|
||||
/>
|
||||
<Line
|
||||
yAxisId="left"
|
||||
type="monotone"
|
||||
dataKey="confidence"
|
||||
name="Confidence"
|
||||
stroke="#10b981"
|
||||
strokeWidth={2}
|
||||
dot={{ r: 3, fill: '#10b981' }}
|
||||
activeDot={{ r: 5 }}
|
||||
/>
|
||||
<Line
|
||||
yAxisId="left"
|
||||
type="monotone"
|
||||
dataKey="contradiction"
|
||||
name="Contradiction"
|
||||
stroke="#f59e0b"
|
||||
strokeWidth={1.5}
|
||||
strokeDasharray="5 5"
|
||||
dot={{ r: 2, fill: '#f59e0b' }}
|
||||
/>
|
||||
{hasPrice && (
|
||||
<Line
|
||||
yAxisId="right"
|
||||
type="monotone"
|
||||
dataKey="price"
|
||||
name="Price"
|
||||
stroke="#e879f9"
|
||||
strokeWidth={2}
|
||||
dot={{ r: 3, fill: '#e879f9' }}
|
||||
activeDot={{ r: 5 }}
|
||||
connectNulls
|
||||
/>
|
||||
)}
|
||||
</LineChart>
|
||||
</ResponsiveContainer>
|
||||
<div className="mb-3 flex items-center justify-between">
|
||||
<h2 className="text-sm font-medium text-gray-400">
|
||||
Trend Strength & Confidence — {ticker} / {selectedWindow}
|
||||
</h2>
|
||||
<button
|
||||
onClick={() => setFullscreen(true)}
|
||||
className="rounded-md border border-surface-700 px-2 py-1 text-xs text-gray-400 hover:bg-surface-800 hover:text-gray-200"
|
||||
title="Expand chart"
|
||||
>
|
||||
⛶ Expand
|
||||
</button>
|
||||
</div>
|
||||
{chartContent(280)}
|
||||
</Card>
|
||||
|
||||
{/* Fullscreen overlay */}
|
||||
{fullscreen && (
|
||||
<div
|
||||
className="fixed inset-0 z-50 flex flex-col bg-surface-950/95 p-6"
|
||||
onClick={(e) => { if (e.target === e.currentTarget) setFullscreen(false); }}
|
||||
role="dialog"
|
||||
aria-label="Expanded chart"
|
||||
>
|
||||
<div className="mb-4 flex items-center justify-between">
|
||||
<h2 className="text-lg font-medium text-gray-200">
|
||||
Trend Strength & Confidence — {ticker} / {selectedWindow}
|
||||
</h2>
|
||||
<button
|
||||
onClick={() => setFullscreen(false)}
|
||||
className="rounded-md border border-surface-700 px-3 py-1.5 text-sm text-gray-400 hover:bg-surface-800 hover:text-gray-200"
|
||||
>
|
||||
✕ Close
|
||||
</button>
|
||||
</div>
|
||||
<div className="flex-1 min-h-0">
|
||||
{chartContent(Math.max(400, window.innerHeight - 160))}
|
||||
</div>
|
||||
</div>
|
||||
)}
|
||||
|
||||
{/* Direction Timeline */}
|
||||
{/* Direction Timeline */}
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">
|
||||
@@ -764,13 +960,13 @@ function TrendHistoryChart({ trends, latestTrends, ticker, marketPrices }: { tre
|
||||
'bg-gray-600';
|
||||
const height = Math.max(8, pt.strength * 0.5);
|
||||
return (
|
||||
<div key={i} className="flex flex-col items-center gap-1" title={`${pt.time}: ${pt.directionLabel} (${pt.strength}%)`}>
|
||||
<div key={i} className="flex flex-col items-center gap-1" title={`${new Date(pt.timestamp).toLocaleString('en-US', { month: 'short', day: 'numeric', hour: 'numeric', minute: '2-digit' })}: ${pt.directionLabel} (${pt.strength}%)`}>
|
||||
<div
|
||||
className={`w-3 rounded-sm ${color}`}
|
||||
style={{ height: `${height}px` }}
|
||||
/>
|
||||
{i % Math.max(1, Math.floor(chartData.length / 8)) === 0 && (
|
||||
<span className="text-[9px] text-gray-500 -rotate-45 origin-top-left whitespace-nowrap">{pt.time}</span>
|
||||
<span className="text-[9px] text-gray-500 -rotate-45 origin-top-left whitespace-nowrap">{new Date(pt.timestamp).toLocaleTimeString('en-US', { hour: 'numeric', minute: '2-digit' })}</span>
|
||||
)}
|
||||
</div>
|
||||
);
|
||||
|
||||
@@ -125,7 +125,7 @@ function SymbolOverview({ ticker }: { ticker: string }) {
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function SentimentHeatmap() {
|
||||
const { data: trends, isLoading } = useTrends({ limit: 500 });
|
||||
const { data: trends, isLoading } = useTrends({ limit: 200 });
|
||||
const { data: companies } = useCompanies();
|
||||
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
@@ -205,7 +205,7 @@ function SentimentHeatmap() {
|
||||
// ---------------------------------------------------------------------------
|
||||
|
||||
function PredictionAccuracy() {
|
||||
const { data: recs, isLoading } = useRecommendations({ limit: 500 });
|
||||
const { data: recs, isLoading } = useRecommendations({ limit: 200 });
|
||||
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (!recs?.length) return <p className="text-sm text-gray-500">No recommendation data available</p>;
|
||||
|
||||
@@ -1,9 +1,89 @@
|
||||
import { useState } from 'react';
|
||||
import { useModelPerformance, useModelFailures } from '../api/hooks';
|
||||
import {
|
||||
useModelPerformance,
|
||||
useModelFailures,
|
||||
useValidationSummary,
|
||||
useValidationCalibration,
|
||||
useValidationICByHorizon,
|
||||
useValidationGateStatus,
|
||||
useValidationAttributionSources,
|
||||
useValidationAttributionCatalysts,
|
||||
useValidationAttributionLayers,
|
||||
} from '../api/hooks';
|
||||
import type {
|
||||
ValidationSummary,
|
||||
ValidationCalibration,
|
||||
CalibrationBucket,
|
||||
ValidationICByHorizon,
|
||||
ICByHorizonEntry,
|
||||
ValidationGateStatus,
|
||||
SourceAttributionResponse,
|
||||
CatalystAttributionResponse,
|
||||
LayerAttributionResponse,
|
||||
SourceAttribution,
|
||||
CatalystAttribution,
|
||||
LayerAttribution,
|
||||
} from '../api/hooks';
|
||||
import { LoadingSpinner, DateRangeSelector, StatusBadge, Card } from '../components/ui';
|
||||
import { AlertTriangle, ShieldCheck, ShieldX } from 'lucide-react';
|
||||
|
||||
type Tab = 'extraction' | 'validation';
|
||||
|
||||
export function OpsModelPage() {
|
||||
const [hours, setHours] = useState(24);
|
||||
const [activeTab, setActiveTab] = useState<Tab>('extraction');
|
||||
|
||||
return (
|
||||
<div className="space-y-6">
|
||||
<div className="flex items-center justify-between">
|
||||
<h1 className="text-xl font-semibold text-gray-100">Model Performance</h1>
|
||||
{activeTab === 'extraction' && (
|
||||
<DateRangeSelector value={hours} onChange={setHours} />
|
||||
)}
|
||||
</div>
|
||||
|
||||
{/* Tab bar */}
|
||||
<div className="flex border-b border-surface-700" role="tablist" aria-label="Model performance tabs">
|
||||
<button
|
||||
role="tab"
|
||||
aria-selected={activeTab === 'extraction'}
|
||||
onClick={() => setActiveTab('extraction')}
|
||||
className={`px-4 py-2 text-sm font-medium transition-colors ${
|
||||
activeTab === 'extraction'
|
||||
? 'border-b-2 border-brand-500 text-brand-400'
|
||||
: 'text-gray-400 hover:text-gray-200'
|
||||
}`}
|
||||
>
|
||||
Extraction Performance
|
||||
</button>
|
||||
<button
|
||||
role="tab"
|
||||
aria-selected={activeTab === 'validation'}
|
||||
onClick={() => setActiveTab('validation')}
|
||||
className={`px-4 py-2 text-sm font-medium transition-colors ${
|
||||
activeTab === 'validation'
|
||||
? 'border-b-2 border-brand-500 text-brand-400'
|
||||
: 'text-gray-400 hover:text-gray-200'
|
||||
}`}
|
||||
>
|
||||
Model Validation
|
||||
</button>
|
||||
</div>
|
||||
|
||||
{activeTab === 'extraction' ? (
|
||||
<ExtractionTab hours={hours} />
|
||||
) : (
|
||||
<ValidationTab />
|
||||
)}
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* Extraction Performance Tab (existing content) */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function ExtractionTab({ hours }: { hours: number }) {
|
||||
const { data: perf, isLoading } = useModelPerformance(hours);
|
||||
const { data: failures } = useModelFailures(hours);
|
||||
|
||||
@@ -13,11 +93,6 @@ export function OpsModelPage() {
|
||||
|
||||
return (
|
||||
<div className="space-y-6">
|
||||
<div className="flex items-center justify-between">
|
||||
<h1 className="text-xl font-semibold text-gray-100">Model Performance</h1>
|
||||
<DateRangeSelector value={hours} onChange={setHours} />
|
||||
</div>
|
||||
|
||||
{/* Key metrics */}
|
||||
<div className="grid grid-cols-2 gap-3 sm:grid-cols-5">
|
||||
<StatCard label="Total Extractions" value={String(p.total_extractions ?? '—')} />
|
||||
@@ -63,6 +138,482 @@ export function OpsModelPage() {
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* Model Validation Tab (new) */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function ValidationTab() {
|
||||
const { data: summary, isLoading: summaryLoading, error: summaryError } = useValidationSummary();
|
||||
const { data: calibration, isLoading: calLoading, error: calError } = useValidationCalibration();
|
||||
const { data: icData, isLoading: icLoading, error: icError } = useValidationICByHorizon();
|
||||
const { data: gateData, isLoading: gateLoading, error: gateError } = useValidationGateStatus();
|
||||
const { data: sourcesData, isLoading: srcLoading, error: srcError } = useValidationAttributionSources();
|
||||
const { data: catalystsData, isLoading: catLoading, error: catError } = useValidationAttributionCatalysts();
|
||||
const { data: layersData, isLoading: layLoading, error: layError } = useValidationAttributionLayers();
|
||||
|
||||
return (
|
||||
<div className="space-y-6">
|
||||
{/* Gate Status */}
|
||||
<GateStatusSection data={gateData} isLoading={gateLoading} error={gateError} />
|
||||
|
||||
{/* Summary Cards */}
|
||||
<SummaryCardsSection data={summary} isLoading={summaryLoading} error={summaryError} />
|
||||
|
||||
{/* Calibration Table */}
|
||||
<CalibrationTableSection data={calibration} isLoading={calLoading} error={calError} />
|
||||
|
||||
{/* IC by Horizon Table */}
|
||||
<ICByHorizonSection data={icData} isLoading={icLoading} error={icError} />
|
||||
|
||||
{/* Source Attribution Table */}
|
||||
<SourceAttributionSection data={sourcesData} isLoading={srcLoading} error={srcError} />
|
||||
|
||||
{/* Catalyst Attribution Table */}
|
||||
<CatalystAttributionSection data={catalystsData} isLoading={catLoading} error={catError} />
|
||||
|
||||
{/* Layer Attribution Table */}
|
||||
<LayerAttributionSection data={layersData} isLoading={layLoading} error={layError} />
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* Gate Status Section */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function GateStatusSection({ data, isLoading, error }: {
|
||||
data: ValidationGateStatus | undefined;
|
||||
isLoading: boolean;
|
||||
error: Error | null;
|
||||
}) {
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (error) return <ErrorCard message="Failed to load gate status" />;
|
||||
|
||||
const gate = data?.gate_status as Record<string, unknown> | null;
|
||||
if (!gate) {
|
||||
return (
|
||||
<Card className="flex items-center gap-3">
|
||||
<ShieldX size={20} className="text-yellow-400" />
|
||||
<div>
|
||||
<div className="text-sm font-medium text-yellow-400">Gate Status Unknown</div>
|
||||
<div className="text-xs text-gray-500">No gate evaluation data available</div>
|
||||
</div>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
const passed = gate.passed as boolean | undefined;
|
||||
const reason = gate.reason as string | undefined;
|
||||
const thresholds = gate.threshold_results as Array<Record<string, unknown>> | undefined;
|
||||
|
||||
return (
|
||||
<Card>
|
||||
<div className="mb-3 flex items-center gap-3">
|
||||
{passed ? (
|
||||
<ShieldCheck size={20} className="text-green-400" />
|
||||
) : (
|
||||
<ShieldX size={20} className="text-red-400" />
|
||||
)}
|
||||
<div>
|
||||
<div className={`text-sm font-medium ${passed ? 'text-green-400' : 'text-red-400'}`}>
|
||||
Live Trading Gate: {passed ? 'PASS' : 'FAIL'}
|
||||
</div>
|
||||
{reason && <div className="text-xs text-gray-500">{reason}</div>}
|
||||
</div>
|
||||
</div>
|
||||
|
||||
{thresholds && thresholds.length > 0 && (
|
||||
<div className="overflow-x-auto">
|
||||
<table className="w-full text-left text-xs">
|
||||
<thead>
|
||||
<tr className="border-b border-surface-700 text-gray-500">
|
||||
<th className="pb-2 pr-4 font-medium">Threshold</th>
|
||||
<th className="pb-2 pr-4 font-medium">Required</th>
|
||||
<th className="pb-2 pr-4 font-medium">Actual</th>
|
||||
<th className="pb-2 font-medium">Status</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{thresholds.map((t, i) => (
|
||||
<tr key={i} className="border-b border-surface-800">
|
||||
<td className="py-1.5 pr-4 text-gray-300">{String(t.name ?? '')}</td>
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-400">{fmtThreshold(t.threshold)}</td>
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-300">{fmtThreshold(t.actual)}</td>
|
||||
<td className="py-1.5">
|
||||
<StatusBadge status={t.passed ? 'success' : 'failed'} />
|
||||
</td>
|
||||
</tr>
|
||||
))}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
)}
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* Summary Cards Section */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function SummaryCardsSection({ data, isLoading, error }: {
|
||||
data: ValidationSummary | undefined;
|
||||
isLoading: boolean;
|
||||
error: Error | null;
|
||||
}) {
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (error) return <ErrorCard message="Failed to load validation summary" />;
|
||||
|
||||
const snap = data?.snapshot;
|
||||
if (!snap) {
|
||||
return (
|
||||
<Card>
|
||||
<p className="text-sm text-gray-500">No validation data available yet. Metrics will appear once predictions have been evaluated.</p>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<div className="grid grid-cols-2 gap-3 sm:grid-cols-3 lg:grid-cols-5">
|
||||
<StatCard label="Predictions" value={String(snap.prediction_count ?? '—')} />
|
||||
<StatCard
|
||||
label="Win Rate"
|
||||
value={fmtPct(snap.win_rate)}
|
||||
color={colorForRate(snap.win_rate, 0.53)}
|
||||
/>
|
||||
<StatCard
|
||||
label="Directional Accuracy"
|
||||
value={fmtPct(snap.directional_accuracy)}
|
||||
color={colorForRate(snap.directional_accuracy, 0.53)}
|
||||
/>
|
||||
<StatCard
|
||||
label="IC"
|
||||
value={fmtIC(snap.information_coefficient)}
|
||||
color={colorForIC(snap.information_coefficient)}
|
||||
/>
|
||||
<StatCard
|
||||
label="Rank IC"
|
||||
value={fmtIC(snap.rank_information_coefficient)}
|
||||
color={colorForIC(snap.rank_information_coefficient)}
|
||||
/>
|
||||
<StatCard
|
||||
label="Brier Score"
|
||||
value={snap.brier_score != null ? snap.brier_score.toFixed(4) : '—'}
|
||||
color={snap.brier_score != null && snap.brier_score < 0.25 ? 'text-green-400' : 'text-gray-100'}
|
||||
/>
|
||||
<StatCard
|
||||
label="ECE"
|
||||
value={snap.calibration_error != null ? snap.calibration_error.toFixed(4) : '—'}
|
||||
color={snap.calibration_error != null && snap.calibration_error < 0.15 ? 'text-green-400' : 'text-yellow-400'}
|
||||
/>
|
||||
<StatCard
|
||||
label="Excess vs SPY"
|
||||
value={fmtPct(snap.avg_excess_return_vs_spy)}
|
||||
color={snap.avg_excess_return_vs_spy != null && snap.avg_excess_return_vs_spy > 0 ? 'text-green-400' : 'text-red-400'}
|
||||
/>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* Calibration Table Section */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function CalibrationTableSection({ data, isLoading, error }: {
|
||||
data: ValidationCalibration | undefined;
|
||||
isLoading: boolean;
|
||||
error: Error | null;
|
||||
}) {
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (error) return <ErrorCard message="Failed to load calibration data" />;
|
||||
|
||||
const buckets = data?.buckets;
|
||||
if (!buckets || buckets.length === 0) {
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-2 text-sm font-medium text-gray-400">Calibration</h2>
|
||||
<p className="text-sm text-gray-500">No calibration data available</p>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Calibration by Confidence Bucket</h2>
|
||||
<div className="overflow-x-auto">
|
||||
<table className="w-full text-left text-xs">
|
||||
<thead>
|
||||
<tr className="border-b border-surface-700 text-gray-500">
|
||||
<th className="pb-2 pr-4 font-medium">Bucket</th>
|
||||
<th className="pb-2 pr-4 font-medium">Avg Confidence</th>
|
||||
<th className="pb-2 pr-4 font-medium">Observed Win Rate</th>
|
||||
<th className="pb-2 pr-4 font-medium">Count</th>
|
||||
<th className="pb-2 font-medium">Status</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{buckets.map((b: CalibrationBucket, i: number) => (
|
||||
<CalibrationRow key={i} bucket={b} />
|
||||
))}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
function CalibrationRow({ bucket }: { bucket: CalibrationBucket }) {
|
||||
const isMiscalibrated = bucket.miscalibrated ||
|
||||
Math.abs(bucket.avg_confidence - bucket.observed_win_rate) > 0.15;
|
||||
|
||||
return (
|
||||
<tr className={`border-b border-surface-800 ${isMiscalibrated ? 'bg-amber-900/20' : ''}`}>
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-300">
|
||||
[{fmtPctShort(bucket.bucket_low)}, {fmtPctShort(bucket.bucket_high)})
|
||||
</td>
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-300">{fmtPctShort(bucket.avg_confidence)}</td>
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-300">{fmtPctShort(bucket.observed_win_rate)}</td>
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-400">{bucket.prediction_count}</td>
|
||||
<td className="py-1.5">
|
||||
{isMiscalibrated ? (
|
||||
<span className="inline-flex items-center gap-1 text-amber-400">
|
||||
<AlertTriangle size={14} />
|
||||
<span>Miscalibrated</span>
|
||||
</span>
|
||||
) : (
|
||||
<span className="text-green-400">OK</span>
|
||||
)}
|
||||
</td>
|
||||
</tr>
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* IC by Horizon Section */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function ICByHorizonSection({ data, isLoading, error }: {
|
||||
data: ValidationICByHorizon | undefined;
|
||||
isLoading: boolean;
|
||||
error: Error | null;
|
||||
}) {
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (error) return <ErrorCard message="Failed to load IC by horizon data" />;
|
||||
|
||||
const horizons = data?.horizons;
|
||||
if (!horizons || horizons.length === 0) {
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-2 text-sm font-medium text-gray-400">IC by Horizon</h2>
|
||||
<p className="text-sm text-gray-500">No IC data available</p>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Information Coefficient by Horizon</h2>
|
||||
<div className="overflow-x-auto">
|
||||
<table className="w-full text-left text-xs">
|
||||
<thead>
|
||||
<tr className="border-b border-surface-700 text-gray-500">
|
||||
<th className="pb-2 pr-4 font-medium">Horizon</th>
|
||||
<th className="pb-2 pr-4 font-medium">IC</th>
|
||||
<th className="pb-2 pr-4 font-medium">Rank IC</th>
|
||||
<th className="pb-2 font-medium">Predictions</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{horizons.map((h: ICByHorizonEntry, i: number) => (
|
||||
<tr key={i} className="border-b border-surface-800">
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-300">{h.horizon}</td>
|
||||
<td className={`py-1.5 pr-4 font-mono ${colorForIC(h.information_coefficient)}`}>
|
||||
{fmtIC(h.information_coefficient)}
|
||||
</td>
|
||||
<td className={`py-1.5 pr-4 font-mono ${colorForIC(h.rank_information_coefficient)}`}>
|
||||
{fmtIC(h.rank_information_coefficient)}
|
||||
</td>
|
||||
<td className="py-1.5 font-mono text-gray-400">{h.prediction_count}</td>
|
||||
</tr>
|
||||
))}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* Source Attribution Section */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function SourceAttributionSection({ data, isLoading, error }: {
|
||||
data: SourceAttributionResponse | undefined;
|
||||
isLoading: boolean;
|
||||
error: Error | null;
|
||||
}) {
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (error) return <ErrorCard message="Failed to load source attribution data" />;
|
||||
|
||||
const sources = data?.sources;
|
||||
if (!sources || sources.length === 0) {
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-2 text-sm font-medium text-gray-400">Source Performance</h2>
|
||||
<p className="text-sm text-gray-500">No source attribution data available</p>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Source Performance</h2>
|
||||
<div className="overflow-x-auto">
|
||||
<table className="w-full text-left text-xs">
|
||||
<thead>
|
||||
<tr className="border-b border-surface-700 text-gray-500">
|
||||
<th className="pb-2 pr-4 font-medium">Source</th>
|
||||
<th className="pb-2 pr-4 font-medium">Win Rate</th>
|
||||
<th className="pb-2 pr-4 font-medium">IC</th>
|
||||
<th className="pb-2 pr-4 font-medium">Avg Return</th>
|
||||
<th className="pb-2 font-medium">Duplicate Rate</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{sources.map((s: SourceAttribution, i: number) => (
|
||||
<tr key={i} className="border-b border-surface-800">
|
||||
<td className="py-1.5 pr-4 text-gray-300">{s.source}</td>
|
||||
<td className={`py-1.5 pr-4 font-mono ${colorForRate(s.win_rate, 0.53)}`}>
|
||||
{fmtPct(s.win_rate)}
|
||||
</td>
|
||||
<td className={`py-1.5 pr-4 font-mono ${colorForIC(s.information_coefficient)}`}>
|
||||
{fmtIC(s.information_coefficient)}
|
||||
</td>
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-300">{fmtPct(s.avg_future_return)}</td>
|
||||
<td className="py-1.5 font-mono text-gray-300">{fmtPct(s.duplicate_rate)}</td>
|
||||
</tr>
|
||||
))}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* Catalyst Attribution Section */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function CatalystAttributionSection({ data, isLoading, error }: {
|
||||
data: CatalystAttributionResponse | undefined;
|
||||
isLoading: boolean;
|
||||
error: Error | null;
|
||||
}) {
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (error) return <ErrorCard message="Failed to load catalyst attribution data" />;
|
||||
|
||||
const catalysts = data?.catalysts;
|
||||
if (!catalysts || catalysts.length === 0) {
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-2 text-sm font-medium text-gray-400">Catalyst Truth Table</h2>
|
||||
<p className="text-sm text-gray-500">No catalyst attribution data available</p>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Catalyst Truth Table</h2>
|
||||
<div className="overflow-x-auto">
|
||||
<table className="w-full text-left text-xs">
|
||||
<thead>
|
||||
<tr className="border-b border-surface-700 text-gray-500">
|
||||
<th className="pb-2 pr-4 font-medium">Catalyst Type</th>
|
||||
<th className="pb-2 pr-4 font-medium">Win Rate</th>
|
||||
<th className="pb-2 pr-4 font-medium">Avg Return</th>
|
||||
<th className="pb-2 font-medium">IC</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{catalysts.map((c: CatalystAttribution, i: number) => (
|
||||
<tr key={i} className="border-b border-surface-800">
|
||||
<td className="py-1.5 pr-4 text-gray-300">{c.catalyst_type}</td>
|
||||
<td className={`py-1.5 pr-4 font-mono ${colorForRate(c.win_rate, 0.53)}`}>
|
||||
{fmtPct(c.win_rate)}
|
||||
</td>
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-300">{fmtPct(c.avg_future_return)}</td>
|
||||
<td className={`py-1.5 font-mono ${colorForIC(c.information_coefficient)}`}>
|
||||
{fmtIC(c.information_coefficient)}
|
||||
</td>
|
||||
</tr>
|
||||
))}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* Layer Attribution Section */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function LayerAttributionSection({ data, isLoading, error }: {
|
||||
data: LayerAttributionResponse | undefined;
|
||||
isLoading: boolean;
|
||||
error: Error | null;
|
||||
}) {
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (error) return <ErrorCard message="Failed to load layer attribution data" />;
|
||||
|
||||
const layers = data?.layers;
|
||||
if (!layers || layers.length === 0) {
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-2 text-sm font-medium text-gray-400">Layer Attribution</h2>
|
||||
<p className="text-sm text-gray-500">No layer attribution data available</p>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Layer Attribution</h2>
|
||||
<div className="overflow-x-auto">
|
||||
<table className="w-full text-left text-xs">
|
||||
<thead>
|
||||
<tr className="border-b border-surface-700 text-gray-500">
|
||||
<th className="pb-2 pr-4 font-medium">Layer</th>
|
||||
<th className="pb-2 pr-4 font-medium">Contribution %</th>
|
||||
<th className="pb-2 pr-4 font-medium">Dominant Win Rate</th>
|
||||
<th className="pb-2 font-medium">IC</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{layers.map((l: LayerAttribution, i: number) => (
|
||||
<tr key={i} className="border-b border-surface-800">
|
||||
<td className="py-1.5 pr-4 text-gray-300 capitalize">{l.layer}</td>
|
||||
<td className="py-1.5 pr-4 font-mono text-gray-300">{fmtPct(l.avg_contribution_pct)}</td>
|
||||
<td className={`py-1.5 pr-4 font-mono ${colorForRate(l.dominant_win_rate, 0.53)}`}>
|
||||
{fmtPct(l.dominant_win_rate)}
|
||||
</td>
|
||||
<td className={`py-1.5 font-mono ${colorForIC(l.dominant_ic)}`}>
|
||||
{fmtIC(l.dominant_ic)}
|
||||
</td>
|
||||
</tr>
|
||||
))}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------ */
|
||||
/* Shared helpers */
|
||||
/* ------------------------------------------------------------------ */
|
||||
|
||||
function StatCard({ label, value, color = 'text-gray-100' }: { label: string; value: string; color?: string }) {
|
||||
return (
|
||||
<Card className="text-center">
|
||||
@@ -71,3 +622,53 @@ function StatCard({ label, value, color = 'text-gray-100' }: { label: string; va
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
function ErrorCard({ message }: { message: string }) {
|
||||
return (
|
||||
<Card className="border-red-700/50 bg-red-900/20">
|
||||
<p className="text-sm text-red-400">{message}</p>
|
||||
</Card>
|
||||
);
|
||||
}
|
||||
|
||||
/** Format a float as percentage with 1 decimal place, or '—' if null */
|
||||
function fmtPct(v: number | null | undefined): string {
|
||||
if (v == null) return '—';
|
||||
return `${(v * 100).toFixed(1)}%`;
|
||||
}
|
||||
|
||||
/** Format a float as short percentage (no decimal) for bucket display */
|
||||
function fmtPctShort(v: number | null | undefined): string {
|
||||
if (v == null) return '—';
|
||||
return `${(v * 100).toFixed(0)}%`;
|
||||
}
|
||||
|
||||
/** Format IC value with 4 decimal places, or '—' if null */
|
||||
function fmtIC(v: number | null | undefined): string {
|
||||
if (v == null) return '—';
|
||||
return v.toFixed(4);
|
||||
}
|
||||
|
||||
/** Format a threshold value for display */
|
||||
function fmtThreshold(v: unknown): string {
|
||||
if (v == null) return '—';
|
||||
if (typeof v === 'number') {
|
||||
if (Number.isInteger(v)) return String(v);
|
||||
return v.toFixed(4);
|
||||
}
|
||||
return String(v);
|
||||
}
|
||||
|
||||
/** Color for win rate / accuracy — green if above threshold, red otherwise */
|
||||
function colorForRate(v: number | null | undefined, threshold: number): string {
|
||||
if (v == null) return 'text-gray-100';
|
||||
return v >= threshold ? 'text-green-400' : 'text-red-400';
|
||||
}
|
||||
|
||||
/** Color for IC — green if positive, red if negative, gray if null */
|
||||
function colorForIC(v: number | null | undefined): string {
|
||||
if (v == null) return 'text-gray-400';
|
||||
if (v >= 0.03) return 'text-green-400';
|
||||
if (v > 0) return 'text-yellow-400';
|
||||
return 'text-red-400';
|
||||
}
|
||||
|
||||
@@ -63,15 +63,18 @@ export function OpsPipelinePage() {
|
||||
const aggregation = (data?.aggregation ?? {}) as Record<string, unknown>;
|
||||
const pipelineEnabled = (data?.pipeline_enabled ?? true) as boolean;
|
||||
|
||||
// Prefer live stream data for queue depths and doc stages, fall back to initial fetch
|
||||
// Queue depths come from live stream (always current)
|
||||
// Document stages: show time-filtered from /health endpoint so numbers are consistent
|
||||
// with Parsing/Extraction/Trends sections. Stream provides live queue data only.
|
||||
const queueDepths = stream?.queue_depths
|
||||
?? (data?.queue_depths as Record<string, number> | undefined)
|
||||
?? {};
|
||||
const docStages = stream?.document_stages
|
||||
?? Object.fromEntries(
|
||||
((data?.document_stages as Array<{ status: string; doc_count: number }>) ?? [])
|
||||
.map((s) => [s.status, s.doc_count]),
|
||||
);
|
||||
const docStages = Object.fromEntries(
|
||||
((data?.document_stages as Array<{ status: string; doc_count: number }>) ?? [])
|
||||
.map((s) => [s.status, s.doc_count]),
|
||||
);
|
||||
// All-time totals from stream for reference
|
||||
const allTimeStages = stream?.document_stages ?? {};
|
||||
|
||||
const failedCount = docStages['extraction_failed'] ?? 0;
|
||||
|
||||
@@ -150,9 +153,13 @@ export function OpsPipelinePage() {
|
||||
|
||||
{/* Document Stage Counts */}
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Document Stages</h2>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">
|
||||
Document Stages
|
||||
<span className="ml-2 text-xs text-gray-600">(last {hours}h)</span>
|
||||
</h2>
|
||||
<div className="grid grid-cols-2 gap-3 sm:grid-cols-4">
|
||||
{Object.entries(docStages).map(([status, count]) => {
|
||||
const allTime = allTimeStages[status];
|
||||
const color = status === 'extracted' ? 'text-green-400'
|
||||
: status === 'parsed' ? 'text-yellow-400'
|
||||
: status === 'extraction_failed' ? 'text-red-400'
|
||||
@@ -162,6 +169,9 @@ export function OpsPipelinePage() {
|
||||
<div key={status} className="rounded-lg border border-surface-700 bg-surface-950 p-3 text-center">
|
||||
<div className={`text-2xl font-bold tabular-nums ${color}`}>{count}</div>
|
||||
<div className="text-xs capitalize text-gray-500">{status.replace('_', ' ')}</div>
|
||||
{allTime != null && allTime !== count && (
|
||||
<div className="mt-0.5 text-[10px] text-gray-600">{allTime} total</div>
|
||||
)}
|
||||
</div>
|
||||
);
|
||||
})}
|
||||
@@ -170,7 +180,10 @@ export function OpsPipelinePage() {
|
||||
|
||||
{/* Parsing Quality */}
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Parsing Quality</h2>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">
|
||||
Parsing Quality
|
||||
<span className="ml-2 text-xs text-gray-600">(last {hours}h)</span>
|
||||
</h2>
|
||||
<dl className="grid grid-cols-2 gap-3 text-sm sm:grid-cols-5">
|
||||
<Stat label="Total Parsed" value={parsing.total_parsed} />
|
||||
<Stat label="High Confidence" value={parsing.high_confidence} color="text-green-400" />
|
||||
@@ -182,7 +195,10 @@ export function OpsPipelinePage() {
|
||||
|
||||
{/* Extraction Stats */}
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Extraction Validation</h2>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">
|
||||
Extraction Validation
|
||||
<span className="ml-2 text-xs text-gray-600">(last {hours}h)</span>
|
||||
</h2>
|
||||
<dl className="grid grid-cols-2 gap-3 text-sm sm:grid-cols-5">
|
||||
<Stat label="Total" value={extraction.total_extractions} />
|
||||
<Stat label="Valid" value={extraction.valid} color="text-green-400" />
|
||||
@@ -194,7 +210,10 @@ export function OpsPipelinePage() {
|
||||
|
||||
{/* Aggregation */}
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Trend Generation</h2>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">
|
||||
Trend Generation
|
||||
<span className="ml-2 text-xs text-gray-600">(last {hours}h)</span>
|
||||
</h2>
|
||||
<dl className="grid grid-cols-2 gap-3 text-sm sm:grid-cols-4">
|
||||
<Stat label="Trends Generated" value={aggregation.trends_generated} />
|
||||
<Stat label="Symbols Covered" value={aggregation.symbols_covered} />
|
||||
|
||||
@@ -2,6 +2,55 @@ import { useParams } from '@tanstack/react-router';
|
||||
import { useOrder } from '../api/hooks';
|
||||
import { StatusBadge, LoadingSpinner, Card } from '../components/ui';
|
||||
|
||||
/**
|
||||
* Lightweight JSON syntax highlighter for read-only display.
|
||||
* Returns React elements with colored spans for keys, strings, numbers, booleans, and null.
|
||||
*/
|
||||
function highlightJson(json: string): React.ReactNode {
|
||||
const parts: React.ReactNode[] = [];
|
||||
// Regex matches JSON tokens: strings, numbers, booleans, null, and structural chars
|
||||
const tokenRe = /("(?:\\.|[^"\\])*")\s*:|("(?:\\.|[^"\\])*")|(-?\d+(?:\.\d+)?(?:[eE][+-]?\d+)?)|(\btrue\b|\bfalse\b)|(\bnull\b)|([{}[\],])/g;
|
||||
let lastIndex = 0;
|
||||
let match: RegExpExecArray | null;
|
||||
|
||||
while ((match = tokenRe.exec(json)) !== null) {
|
||||
// Add any whitespace/text between tokens
|
||||
if (match.index > lastIndex) {
|
||||
parts.push(json.slice(lastIndex, match.index));
|
||||
}
|
||||
|
||||
if (match[1]) {
|
||||
// Key (string followed by colon)
|
||||
parts.push(<span key={match.index} className="text-cyan-400">{match[1]}</span>);
|
||||
parts.push(':');
|
||||
} else if (match[2]) {
|
||||
// String value
|
||||
parts.push(<span key={match.index} className="text-green-400">{match[2]}</span>);
|
||||
} else if (match[3]) {
|
||||
// Number
|
||||
parts.push(<span key={match.index} className="text-yellow-300">{match[3]}</span>);
|
||||
} else if (match[4]) {
|
||||
// Boolean
|
||||
parts.push(<span key={match.index} className="text-purple-400">{match[4]}</span>);
|
||||
} else if (match[5]) {
|
||||
// Null
|
||||
parts.push(<span key={match.index} className="text-red-400">{match[5]}</span>);
|
||||
} else if (match[6]) {
|
||||
// Structural characters
|
||||
parts.push(<span key={match.index} className="text-gray-500">{match[6]}</span>);
|
||||
}
|
||||
|
||||
lastIndex = match.index + match[0].length;
|
||||
}
|
||||
|
||||
// Remaining text
|
||||
if (lastIndex < json.length) {
|
||||
parts.push(json.slice(lastIndex));
|
||||
}
|
||||
|
||||
return <>{parts}</>;
|
||||
}
|
||||
|
||||
export function OrderDetailPage() {
|
||||
const { id } = useParams({ from: '/orders/$id' });
|
||||
const { data: order, isLoading } = useOrder(id);
|
||||
@@ -33,8 +82,8 @@ export function OrderDetailPage() {
|
||||
{order.decision_trace && Object.keys(order.decision_trace).length > 0 && (
|
||||
<Card>
|
||||
<h2 className="mb-2 text-sm font-medium text-gray-400">Decision Trace</h2>
|
||||
<pre className="overflow-x-auto rounded bg-surface-950 p-3 text-xs text-gray-300">
|
||||
{JSON.stringify(order.decision_trace, null, 2)}
|
||||
<pre className="overflow-x-auto rounded bg-surface-950 p-3 text-xs leading-relaxed">
|
||||
{highlightJson(JSON.stringify(order.decision_trace, null, 2))}
|
||||
</pre>
|
||||
</Card>
|
||||
)}
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
import { usePositions } from '../api/hooks';
|
||||
import { Link } from '@tanstack/react-router';
|
||||
import { usePositions, useCompanies } from '../api/hooks';
|
||||
import { DataTable, type Column } from '../components/DataTable';
|
||||
import { LoadingSpinner } from '../components/ui';
|
||||
import type { Position } from '../api/hooks';
|
||||
@@ -13,18 +14,38 @@ function pnlColor(v: number | null | undefined) {
|
||||
return v >= 0 ? 'text-green-400' : 'text-red-400';
|
||||
}
|
||||
|
||||
const columns: Column<Position>[] = [
|
||||
{ key: 'ticker', header: 'Ticker', className: 'font-mono font-semibold text-brand-300' },
|
||||
{ key: 'quantity', header: 'Qty' },
|
||||
{ key: 'avg_entry_price', header: 'Entry', render: (r) => <span>{fmtUsd(r.avg_entry_price)}</span> },
|
||||
{ key: 'current_price', header: 'Current', render: (r) => <span>{fmtUsd(r.current_price)}</span> },
|
||||
{ key: 'unrealized_pnl', header: 'Unrealized P&L', render: (r) => <span className={pnlColor(r.unrealized_pnl)}>{fmtUsd(r.unrealized_pnl)}</span> },
|
||||
{ key: 'realized_pnl', header: 'Realized P&L', render: (r) => <span className={pnlColor(r.realized_pnl)}>{fmtUsd(r.realized_pnl)}</span> },
|
||||
{ key: 'updated_at', header: 'Updated', render: (r) => <span className="text-xs">{new Date(r.updated_at).toLocaleString()}</span> },
|
||||
];
|
||||
|
||||
export function PositionsPage() {
|
||||
const { data, isLoading } = usePositions();
|
||||
const { data: companies } = useCompanies();
|
||||
|
||||
// Build ticker → company ID lookup
|
||||
const tickerToId: Record<string, string> = {};
|
||||
for (const c of companies ?? []) {
|
||||
tickerToId[c.ticker] = c.id;
|
||||
}
|
||||
|
||||
const posColumns: Column<Position>[] = [
|
||||
{
|
||||
key: 'ticker',
|
||||
header: 'Ticker',
|
||||
render: (r) => {
|
||||
const companyId = tickerToId[r.ticker];
|
||||
return companyId ? (
|
||||
<Link to="/companies/$id" params={{ id: companyId }} className="font-mono font-semibold text-brand-300 hover:underline">
|
||||
{r.ticker}
|
||||
</Link>
|
||||
) : (
|
||||
<span className="font-mono font-semibold text-brand-300">{r.ticker}</span>
|
||||
);
|
||||
},
|
||||
},
|
||||
{ key: 'quantity', header: 'Qty' },
|
||||
{ key: 'avg_entry_price', header: 'Entry', render: (r) => <span>{fmtUsd(r.avg_entry_price)}</span> },
|
||||
{ key: 'current_price', header: 'Current', render: (r) => <span>{fmtUsd(r.current_price)}</span> },
|
||||
{ key: 'unrealized_pnl', header: 'Unrealized P&L', render: (r) => <span className={pnlColor(r.unrealized_pnl)}>{fmtUsd(r.unrealized_pnl)}</span> },
|
||||
{ key: 'realized_pnl', header: 'Realized P&L', render: (r) => <span className={pnlColor(r.realized_pnl)}>{fmtUsd(r.realized_pnl)}</span> },
|
||||
{ key: 'updated_at', header: 'Updated', render: (r) => <span className="text-xs">{new Date(r.updated_at).toLocaleString()}</span> },
|
||||
];
|
||||
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
|
||||
@@ -58,7 +79,7 @@ export function PositionsPage() {
|
||||
<h1 className="mb-4 text-xl font-semibold text-gray-100">Positions</h1>
|
||||
<DataTable<Position>
|
||||
data={positions}
|
||||
columns={columns}
|
||||
columns={posColumns}
|
||||
keyField="id"
|
||||
footerRow={footer}
|
||||
/>
|
||||
|
||||
@@ -1,13 +1,92 @@
|
||||
/**
|
||||
* Recommendation detail page with validation context.
|
||||
*
|
||||
* Shows original confidence alongside calibrated confidence (historical win rate),
|
||||
* evidence quality indicators, source reliability, and live eligibility status.
|
||||
*
|
||||
* Requirements: 13.1, 13.2, 13.3, 13.4, 13.5, 13.6, 13.7
|
||||
*/
|
||||
import { useParams, Link } from '@tanstack/react-router';
|
||||
import { useRecommendation } from '../api/hooks';
|
||||
import { AlertTriangle, ShieldCheck, ShieldX, Info } from 'lucide-react';
|
||||
import {
|
||||
useRecommendation,
|
||||
useValidationCalibration,
|
||||
useValidationGateStatus,
|
||||
useValidationAttributionSources,
|
||||
} from '../api/hooks';
|
||||
import { StatusBadge, ConfidenceBar, LoadingSpinner, Card } from '../components/ui';
|
||||
|
||||
export function RecommendationDetailPage() {
|
||||
const { id } = useParams({ from: '/recommendations/$id' });
|
||||
const { data: rec, isLoading } = useRecommendation(id);
|
||||
const { data: calibration } = useValidationCalibration();
|
||||
const { data: gateData } = useValidationGateStatus();
|
||||
const { data: sourcesData } = useValidationAttributionSources();
|
||||
|
||||
if (isLoading || !rec) return <LoadingSpinner />;
|
||||
|
||||
// --- Calibration: find the bucket matching this recommendation's confidence ---
|
||||
const matchingBucket = calibration?.buckets?.find(
|
||||
(b) => rec.confidence >= b.bucket_low && rec.confidence < b.bucket_high,
|
||||
);
|
||||
// Handle edge case: confidence of exactly 1.0 falls in the last bucket [0.90, 1.00]
|
||||
const calibratedBucket =
|
||||
matchingBucket ??
|
||||
(rec.confidence >= 1.0
|
||||
? calibration?.buckets?.find((b) => b.bucket_high >= 1.0)
|
||||
: undefined);
|
||||
|
||||
const historicalWinRate = calibratedBucket?.observed_win_rate;
|
||||
|
||||
// --- Evidence counts ---
|
||||
const totalEvidenceCount = rec.evidence.length;
|
||||
// Compute duplicate evidence: group by normalized title, count extras
|
||||
const titleCounts = new Map<string, number>();
|
||||
for (const ev of rec.evidence) {
|
||||
const key = (ev.title ?? '').toLowerCase().trim();
|
||||
titleCounts.set(key, (titleCounts.get(key) ?? 0) + 1);
|
||||
}
|
||||
let duplicateEvidenceCount = 0;
|
||||
for (const count of titleCounts.values()) {
|
||||
if (count > 1) duplicateEvidenceCount += count - 1;
|
||||
}
|
||||
const uniqueEvidenceCount = totalEvidenceCount - duplicateEvidenceCount;
|
||||
const duplicateRatio = totalEvidenceCount > 0 ? duplicateEvidenceCount / totalEvidenceCount : 0;
|
||||
const hasDuplicateWarning = duplicateRatio > 0.2;
|
||||
|
||||
// --- Source reliability: find primary contributing sources ---
|
||||
const evidenceSources = new Map<string, number>();
|
||||
for (const ev of rec.evidence) {
|
||||
const src = ev.source_type ?? ev.publisher ?? 'unknown';
|
||||
evidenceSources.set(src, (evidenceSources.get(src) ?? 0) + ev.weight);
|
||||
}
|
||||
// Sort by total weight descending to find primary source
|
||||
const sortedSources = [...evidenceSources.entries()].sort((a, b) => b[1] - a[1]);
|
||||
const primarySourceType = sortedSources[0]?.[0];
|
||||
|
||||
// Look up source reliability from attribution data
|
||||
const primarySourceAttribution = sourcesData?.sources?.find(
|
||||
(s) => s.source_type === primarySourceType || s.source === primarySourceType,
|
||||
);
|
||||
// Source reliability is approximated from win_rate via Bayesian shrinkage
|
||||
// The attribution data has win_rate which is the observed metric
|
||||
const primarySourceWinRate = primarySourceAttribution?.win_rate;
|
||||
// Bayesian shrinkage: reliability = 0.5 + (n/(n+30)) * (win_rate - 0.5)
|
||||
const primarySourceCount = primarySourceAttribution?.prediction_count ?? 0;
|
||||
const primarySourceReliability =
|
||||
primarySourceWinRate != null
|
||||
? 0.5 + (primarySourceCount / (primarySourceCount + 30)) * (primarySourceWinRate - 0.5)
|
||||
: undefined;
|
||||
const hasLowReliabilityWarning =
|
||||
primarySourceReliability != null && primarySourceReliability < 0.4;
|
||||
|
||||
// --- Gate status ---
|
||||
const gateStatus = gateData?.gate_status as {
|
||||
passed?: boolean;
|
||||
reason?: string;
|
||||
threshold_results?: Array<{ name: string; threshold: number; actual: number; passed: boolean }>;
|
||||
} | null;
|
||||
|
||||
return (
|
||||
<div className="space-y-6">
|
||||
<div className="flex items-center gap-3">
|
||||
@@ -28,6 +107,137 @@ export function RecommendationDetailPage() {
|
||||
</dl>
|
||||
</Card>
|
||||
|
||||
{/* Validation Context Card — Requirements 13.1–13.7 */}
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Validation Context</h2>
|
||||
<dl className="grid grid-cols-2 gap-x-8 gap-y-3 text-sm sm:grid-cols-3">
|
||||
{/* 13.1: Original confidence alongside calibrated confidence */}
|
||||
<div>
|
||||
<dt className="text-gray-500">Original Confidence</dt>
|
||||
<dd className="text-gray-200">{(rec.confidence * 100).toFixed(1)}%</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Calibrated Confidence</dt>
|
||||
<dd className="text-gray-200">
|
||||
{historicalWinRate != null
|
||||
? `${(historicalWinRate * 100).toFixed(1)}%`
|
||||
: 'N/A'}
|
||||
</dd>
|
||||
</div>
|
||||
|
||||
{/* 13.2: Historical win rate for similar confidence levels */}
|
||||
<div>
|
||||
<dt className="text-gray-500">Historical Win Rate</dt>
|
||||
<dd className="text-gray-200">
|
||||
{historicalWinRate != null ? (
|
||||
<span>
|
||||
{(historicalWinRate * 100).toFixed(1)}%
|
||||
{calibratedBucket && (
|
||||
<span className="ml-1 text-xs text-gray-500">
|
||||
({calibratedBucket.prediction_count} predictions)
|
||||
</span>
|
||||
)}
|
||||
</span>
|
||||
) : (
|
||||
'N/A'
|
||||
)}
|
||||
</dd>
|
||||
</div>
|
||||
|
||||
{/* 13.3: Evidence count, unique evidence count, duplicate evidence count */}
|
||||
<div>
|
||||
<dt className="text-gray-500">Evidence Count</dt>
|
||||
<dd className="text-gray-200">{totalEvidenceCount}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="text-gray-500">Unique Evidence</dt>
|
||||
<dd className="text-gray-200">{uniqueEvidenceCount}</dd>
|
||||
</div>
|
||||
<div>
|
||||
<dt className="flex items-center gap-1 text-gray-500">
|
||||
Duplicate Evidence
|
||||
{/* 13.6: Warning badge when duplicate evidence count > 20% of total */}
|
||||
{hasDuplicateWarning && (
|
||||
<span
|
||||
className="inline-flex items-center gap-0.5 rounded-full border border-yellow-700/50 bg-yellow-900/40 px-1.5 py-0.5 text-[10px] font-medium text-yellow-400"
|
||||
title="Duplicate evidence exceeds 20% of total — potential evidence inflation"
|
||||
>
|
||||
<AlertTriangle size={10} />
|
||||
>20%
|
||||
</span>
|
||||
)}
|
||||
</dt>
|
||||
<dd className="text-gray-200">
|
||||
{duplicateEvidenceCount}
|
||||
{totalEvidenceCount > 0 && (
|
||||
<span className="ml-1 text-xs text-gray-500">
|
||||
({(duplicateRatio * 100).toFixed(0)}%)
|
||||
</span>
|
||||
)}
|
||||
</dd>
|
||||
</div>
|
||||
|
||||
{/* 13.4: Source reliability indicator */}
|
||||
<div>
|
||||
<dt className="flex items-center gap-1 text-gray-500">
|
||||
Primary Source Reliability
|
||||
{/* 13.7: Warning badge when primary source reliability < 0.4 */}
|
||||
{hasLowReliabilityWarning && (
|
||||
<span
|
||||
className="inline-flex items-center gap-0.5 rounded-full border border-red-700/50 bg-red-900/40 px-1.5 py-0.5 text-[10px] font-medium text-red-400"
|
||||
title="Primary source reliability is below 0.4 — low or unknown reliability"
|
||||
>
|
||||
<AlertTriangle size={10} />
|
||||
Low
|
||||
</span>
|
||||
)}
|
||||
</dt>
|
||||
<dd className="text-gray-200">
|
||||
{primarySourceReliability != null ? (
|
||||
<span>
|
||||
{primarySourceReliability.toFixed(3)}
|
||||
{primarySourceType && (
|
||||
<span className="ml-1 text-xs text-gray-500">({primarySourceType})</span>
|
||||
)}
|
||||
</span>
|
||||
) : (
|
||||
'N/A'
|
||||
)}
|
||||
</dd>
|
||||
</div>
|
||||
|
||||
{/* 13.5: Live eligibility status with reason */}
|
||||
<div className="col-span-2">
|
||||
<dt className="text-gray-500">Live Eligibility</dt>
|
||||
<dd>
|
||||
{gateStatus != null ? (
|
||||
<div className="flex items-center gap-2">
|
||||
{gateStatus.passed ? (
|
||||
<span className="inline-flex items-center gap-1 text-green-400">
|
||||
<ShieldCheck size={14} />
|
||||
Gate Passed
|
||||
</span>
|
||||
) : (
|
||||
<span className="inline-flex items-center gap-1 text-red-400">
|
||||
<ShieldX size={14} />
|
||||
Gate Failed
|
||||
</span>
|
||||
)}
|
||||
{gateStatus.reason && (
|
||||
<span className="text-xs text-gray-500">{gateStatus.reason}</span>
|
||||
)}
|
||||
</div>
|
||||
) : (
|
||||
<span className="inline-flex items-center gap-1 text-gray-500">
|
||||
<Info size={14} />
|
||||
N/A — no gate evaluation available
|
||||
</span>
|
||||
)}
|
||||
</dd>
|
||||
</div>
|
||||
</dl>
|
||||
</Card>
|
||||
|
||||
{rec.thesis && (
|
||||
<Card>
|
||||
<h2 className="mb-2 text-sm font-medium text-gray-400">Thesis</h2>
|
||||
|
||||
@@ -0,0 +1,275 @@
|
||||
import { useParams, Link } from '@tanstack/react-router';
|
||||
import { useReport } from '../api/hooks';
|
||||
import { LoadingSpinner, StatusBadge, Card } from '../components/ui';
|
||||
import { ArrowLeft } from 'lucide-react';
|
||||
|
||||
interface PLSection {
|
||||
realized_pnl: number;
|
||||
unrealized_pnl: number;
|
||||
daily_return: number;
|
||||
cumulative_return: number;
|
||||
win_count: number;
|
||||
loss_count: number;
|
||||
win_rate: number;
|
||||
profit_factor: number;
|
||||
sharpe_ratio: number;
|
||||
summary: string;
|
||||
validation_warnings?: { field_name: string; computed_value: number; snapshot_value: number; pct_difference: number }[];
|
||||
}
|
||||
|
||||
interface PositionDetail {
|
||||
ticker: string;
|
||||
entry_price: number;
|
||||
current_or_exit_price: number;
|
||||
pnl: number;
|
||||
pnl_pct: number;
|
||||
hold_duration_hours: number;
|
||||
status: string;
|
||||
}
|
||||
|
||||
interface RiskMetrics {
|
||||
current_risk_tier: string;
|
||||
portfolio_heat: number;
|
||||
max_drawdown: number;
|
||||
current_drawdown_pct: number;
|
||||
reserve_pool_balance: number;
|
||||
circuit_breaker_event_count: number;
|
||||
summary: string;
|
||||
}
|
||||
|
||||
interface ModelWindow {
|
||||
lookback: string;
|
||||
win_rate: number | null;
|
||||
directional_accuracy: number | null;
|
||||
information_coefficient: number | null;
|
||||
calibration_error: number | null;
|
||||
brier_score: number | null;
|
||||
}
|
||||
|
||||
interface ReportData {
|
||||
pnl: PLSection;
|
||||
recommendation_accuracy: {
|
||||
total_evaluated: number;
|
||||
act_count: number;
|
||||
skip_count: number;
|
||||
acted_win_rate: number;
|
||||
avg_confidence_acted: number;
|
||||
avg_confidence_skipped: number;
|
||||
summary: string;
|
||||
validation_warnings?: { field_name: string; pct_difference: number }[];
|
||||
};
|
||||
position_performance: {
|
||||
positions: PositionDetail[];
|
||||
summary: string;
|
||||
};
|
||||
risk_metrics: RiskMetrics;
|
||||
model_quality: {
|
||||
windows: ModelWindow[];
|
||||
summary: string;
|
||||
validation_warnings?: { field_name: string; pct_difference: number }[];
|
||||
};
|
||||
executive_summary: string;
|
||||
validation_status: string;
|
||||
}
|
||||
|
||||
function MetricCard({ label, value, sub }: { label: string; value: string; sub?: string }) {
|
||||
return (
|
||||
<div className="rounded-lg bg-surface-800 border border-surface-700 p-3">
|
||||
<div className="text-xs text-gray-400 mb-1">{label}</div>
|
||||
<div className="text-lg font-semibold text-gray-100">{value}</div>
|
||||
{sub && <div className="text-xs text-gray-500 mt-0.5">{sub}</div>}
|
||||
</div>
|
||||
);
|
||||
}
|
||||
|
||||
function pct(v: number) {
|
||||
return `${(v * 100).toFixed(2)}%`;
|
||||
}
|
||||
|
||||
function dollar(v: number) {
|
||||
return v >= 0 ? `$${v.toFixed(2)}` : `-$${Math.abs(v).toFixed(2)}`;
|
||||
}
|
||||
|
||||
export function ReportDetailPage() {
|
||||
const { id } = useParams({ from: '/reports/$id' });
|
||||
const { data, isLoading } = useReport(id);
|
||||
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (!data) return <div className="text-gray-400">Report not found</div>;
|
||||
|
||||
const report = data.report_data as unknown as ReportData;
|
||||
|
||||
return (
|
||||
<div className="space-y-6">
|
||||
{/* Header */}
|
||||
<div className="flex items-center gap-3">
|
||||
<Link to="/reports" className="text-gray-400 hover:text-gray-200">
|
||||
<ArrowLeft size={20} />
|
||||
</Link>
|
||||
<div>
|
||||
<h1 className="text-xl font-semibold text-gray-100">
|
||||
{data.report_type === 'daily' ? 'Daily' : 'Weekly'} Report
|
||||
</h1>
|
||||
<p className="text-sm text-gray-400">
|
||||
{data.period_start === data.period_end
|
||||
? data.period_start
|
||||
: `${data.period_start} → ${data.period_end}`}
|
||||
{' · '}
|
||||
<StatusBadge status={data.validation_status} />
|
||||
</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
{/* Executive Summary */}
|
||||
{report.executive_summary && (
|
||||
<Card>
|
||||
<h2 className="text-sm font-medium text-gray-300 mb-2">Executive Summary</h2>
|
||||
<p className="text-sm text-gray-200 whitespace-pre-wrap leading-relaxed">
|
||||
{report.executive_summary}
|
||||
</p>
|
||||
</Card>
|
||||
)}
|
||||
|
||||
{/* P&L Section */}
|
||||
<Card>
|
||||
<h2 className="text-sm font-medium text-gray-300 mb-3">P&L</h2>
|
||||
<div className="grid grid-cols-2 md:grid-cols-4 gap-3 mb-3">
|
||||
<MetricCard label="Realized P&L" value={dollar(report.pnl.realized_pnl)} />
|
||||
<MetricCard label="Unrealized P&L" value={dollar(report.pnl.unrealized_pnl)} />
|
||||
<MetricCard label="Daily Return" value={pct(report.pnl.daily_return)} />
|
||||
<MetricCard label="Cumulative Return" value={pct(report.pnl.cumulative_return)} />
|
||||
<MetricCard label="Win Rate" value={pct(report.pnl.win_rate)} sub={`${report.pnl.win_count}W / ${report.pnl.loss_count}L`} />
|
||||
<MetricCard label="Profit Factor" value={report.pnl.profit_factor.toFixed(2)} />
|
||||
<MetricCard label="Sharpe Ratio" value={report.pnl.sharpe_ratio.toFixed(2)} />
|
||||
</div>
|
||||
{report.pnl.summary && (
|
||||
<p className="text-xs text-gray-400 mt-2">{report.pnl.summary}</p>
|
||||
)}
|
||||
</Card>
|
||||
|
||||
{/* Recommendation Accuracy */}
|
||||
<Card>
|
||||
<h2 className="text-sm font-medium text-gray-300 mb-3">Recommendation Accuracy</h2>
|
||||
<div className="grid grid-cols-2 md:grid-cols-4 gap-3 mb-3">
|
||||
<MetricCard label="Total Evaluated" value={String(report.recommendation_accuracy.total_evaluated)} />
|
||||
<MetricCard label="Acted" value={String(report.recommendation_accuracy.act_count)} />
|
||||
<MetricCard label="Skipped" value={String(report.recommendation_accuracy.skip_count)} />
|
||||
<MetricCard label="Acted Win Rate" value={pct(report.recommendation_accuracy.acted_win_rate)} />
|
||||
<MetricCard label="Avg Confidence (Acted)" value={report.recommendation_accuracy.avg_confidence_acted.toFixed(3)} />
|
||||
<MetricCard label="Avg Confidence (Skipped)" value={report.recommendation_accuracy.avg_confidence_skipped.toFixed(3)} />
|
||||
</div>
|
||||
{report.recommendation_accuracy.validation_warnings && report.recommendation_accuracy.validation_warnings.length > 0 && (
|
||||
<div className="mt-2 rounded bg-yellow-900/20 border border-yellow-700/30 p-2">
|
||||
<span className="text-xs text-yellow-400">⚠ Validation warnings:</span>
|
||||
{report.recommendation_accuracy.validation_warnings.map((w, i) => (
|
||||
<span key={i} className="text-xs text-yellow-300 ml-2">{w.field_name} ({w.pct_difference.toFixed(1)}% off)</span>
|
||||
))}
|
||||
</div>
|
||||
)}
|
||||
{report.recommendation_accuracy.summary && (
|
||||
<p className="text-xs text-gray-400 mt-2">{report.recommendation_accuracy.summary}</p>
|
||||
)}
|
||||
</Card>
|
||||
|
||||
{/* Position Performance */}
|
||||
<Card>
|
||||
<h2 className="text-sm font-medium text-gray-300 mb-3">
|
||||
Positions ({report.position_performance.positions.length})
|
||||
</h2>
|
||||
{report.position_performance.positions.length > 0 ? (
|
||||
<div className="overflow-x-auto">
|
||||
<table className="w-full text-sm">
|
||||
<thead>
|
||||
<tr className="text-left text-xs text-gray-400 border-b border-surface-700">
|
||||
<th className="pb-2 pr-4">Ticker</th>
|
||||
<th className="pb-2 pr-4">Status</th>
|
||||
<th className="pb-2 pr-4">Entry</th>
|
||||
<th className="pb-2 pr-4">Current/Exit</th>
|
||||
<th className="pb-2 pr-4">P&L</th>
|
||||
<th className="pb-2 pr-4">P&L %</th>
|
||||
<th className="pb-2">Hold (hrs)</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{report.position_performance.positions.map((p, i) => (
|
||||
<tr key={i} className="border-b border-surface-800 text-gray-200">
|
||||
<td className="py-1.5 pr-4 font-mono font-semibold text-brand-300">{p.ticker}</td>
|
||||
<td className="py-1.5 pr-4"><StatusBadge status={p.status} /></td>
|
||||
<td className="py-1.5 pr-4">${p.entry_price.toFixed(2)}</td>
|
||||
<td className="py-1.5 pr-4">${p.current_or_exit_price.toFixed(2)}</td>
|
||||
<td className={`py-1.5 pr-4 font-mono ${p.pnl >= 0 ? 'text-green-400' : 'text-red-400'}`}>
|
||||
{dollar(p.pnl)}
|
||||
</td>
|
||||
<td className={`py-1.5 pr-4 ${p.pnl_pct >= 0 ? 'text-green-400' : 'text-red-400'}`}>
|
||||
{p.pnl_pct.toFixed(2)}%
|
||||
</td>
|
||||
<td className="py-1.5 text-gray-400">{p.hold_duration_hours.toFixed(1)}</td>
|
||||
</tr>
|
||||
))}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
) : (
|
||||
<p className="text-sm text-gray-500">No positions during this period.</p>
|
||||
)}
|
||||
{report.position_performance.summary && (
|
||||
<p className="text-xs text-gray-400 mt-3">{report.position_performance.summary}</p>
|
||||
)}
|
||||
</Card>
|
||||
|
||||
{/* Risk Metrics */}
|
||||
<Card>
|
||||
<h2 className="text-sm font-medium text-gray-300 mb-3">Risk Metrics</h2>
|
||||
<div className="grid grid-cols-2 md:grid-cols-3 gap-3">
|
||||
<MetricCard label="Risk Tier" value={report.risk_metrics.current_risk_tier} />
|
||||
<MetricCard label="Portfolio Heat" value={pct(report.risk_metrics.portfolio_heat)} />
|
||||
<MetricCard label="Max Drawdown" value={pct(report.risk_metrics.max_drawdown)} />
|
||||
<MetricCard label="Current Drawdown" value={pct(report.risk_metrics.current_drawdown_pct)} />
|
||||
<MetricCard label="Reserve Pool" value={dollar(report.risk_metrics.reserve_pool_balance)} />
|
||||
<MetricCard label="Circuit Breaker Events" value={String(report.risk_metrics.circuit_breaker_event_count)} />
|
||||
</div>
|
||||
{report.risk_metrics.summary && (
|
||||
<p className="text-xs text-gray-400 mt-3">{report.risk_metrics.summary}</p>
|
||||
)}
|
||||
</Card>
|
||||
|
||||
{/* Model Quality */}
|
||||
<Card>
|
||||
<h2 className="text-sm font-medium text-gray-300 mb-3">Model Quality</h2>
|
||||
{report.model_quality.windows.length > 0 ? (
|
||||
<div className="overflow-x-auto">
|
||||
<table className="w-full text-sm">
|
||||
<thead>
|
||||
<tr className="text-left text-xs text-gray-400 border-b border-surface-700">
|
||||
<th className="pb-2 pr-4">Window</th>
|
||||
<th className="pb-2 pr-4">Win Rate</th>
|
||||
<th className="pb-2 pr-4">Dir. Accuracy</th>
|
||||
<th className="pb-2 pr-4">IC</th>
|
||||
<th className="pb-2 pr-4">ECE</th>
|
||||
<th className="pb-2">Brier</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
{report.model_quality.windows.map((w, i) => (
|
||||
<tr key={i} className="border-b border-surface-800 text-gray-200">
|
||||
<td className="py-1.5 pr-4 font-medium">{w.lookback}</td>
|
||||
<td className="py-1.5 pr-4">{w.win_rate != null ? pct(w.win_rate) : '—'}</td>
|
||||
<td className="py-1.5 pr-4">{w.directional_accuracy != null ? pct(w.directional_accuracy) : '—'}</td>
|
||||
<td className="py-1.5 pr-4">{w.information_coefficient != null ? w.information_coefficient.toFixed(4) : '—'}</td>
|
||||
<td className="py-1.5 pr-4">{w.calibration_error != null ? w.calibration_error.toFixed(4) : '—'}</td>
|
||||
<td className="py-1.5">{w.brier_score != null ? w.brier_score.toFixed(4) : '—'}</td>
|
||||
</tr>
|
||||
))}
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
) : (
|
||||
<p className="text-sm text-gray-500">No model quality data available.</p>
|
||||
)}
|
||||
{report.model_quality.summary && (
|
||||
<p className="text-xs text-gray-400 mt-3">{report.model_quality.summary}</p>
|
||||
)}
|
||||
</Card>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
@@ -0,0 +1,79 @@
|
||||
import { useState } from 'react';
|
||||
import { useNavigate } from '@tanstack/react-router';
|
||||
import { useReports } from '../api/hooks';
|
||||
import { DataTable, type Column } from '../components/DataTable';
|
||||
import { StatusBadge, LoadingSpinner } from '../components/ui';
|
||||
import type { ReportListItem } from '../api/hooks';
|
||||
|
||||
export function ReportsPage() {
|
||||
const navigate = useNavigate();
|
||||
const [reportType, setReportType] = useState('');
|
||||
const { data, isLoading } = useReports({
|
||||
report_type: reportType || undefined,
|
||||
limit: 50,
|
||||
});
|
||||
|
||||
const columns: Column<ReportListItem>[] = [
|
||||
{
|
||||
key: 'report_type',
|
||||
header: 'Type',
|
||||
render: (r) => (
|
||||
<span className="inline-flex items-center rounded px-2 py-0.5 text-xs font-medium bg-surface-700 text-brand-300 capitalize">
|
||||
{r.report_type}
|
||||
</span>
|
||||
),
|
||||
},
|
||||
{
|
||||
key: 'period_start',
|
||||
header: 'Period',
|
||||
render: (r) =>
|
||||
r.period_start === r.period_end
|
||||
? r.period_start
|
||||
: `${r.period_start} → ${r.period_end}`,
|
||||
},
|
||||
{
|
||||
key: 'validation_status',
|
||||
header: 'Validation',
|
||||
render: (r) => <StatusBadge status={r.validation_status} />,
|
||||
},
|
||||
{
|
||||
key: 'generated_at',
|
||||
header: 'Generated',
|
||||
render: (r) => (
|
||||
<span className="text-xs text-gray-400">
|
||||
{new Date(r.generated_at).toLocaleString()}
|
||||
</span>
|
||||
),
|
||||
},
|
||||
];
|
||||
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
|
||||
return (
|
||||
<div>
|
||||
<div className="mb-4 flex items-center justify-between">
|
||||
<h1 className="text-xl font-semibold text-gray-100">
|
||||
Trading Reports
|
||||
</h1>
|
||||
<select
|
||||
value={reportType}
|
||||
onChange={(e) => setReportType(e.target.value)}
|
||||
className="rounded border border-surface-600 bg-surface-800 px-3 py-1.5 text-sm text-gray-200 focus:border-brand-500 focus:outline-none"
|
||||
aria-label="Filter by report type"
|
||||
>
|
||||
<option value="">All Types</option>
|
||||
<option value="daily">Daily</option>
|
||||
<option value="weekly">Weekly</option>
|
||||
</select>
|
||||
</div>
|
||||
<DataTable<ReportListItem>
|
||||
data={data ?? []}
|
||||
columns={columns}
|
||||
keyField="id"
|
||||
onRowClick={(row) =>
|
||||
navigate({ to: '/reports/$id', params: { id: row.id } })
|
||||
}
|
||||
/>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
@@ -116,7 +116,7 @@ export function TradingPage() {
|
||||
|
||||
{/* Paper Trading Reset */}
|
||||
<ResetCard
|
||||
onReset={() => resetTrading.mutate(0)}
|
||||
onReset={(params) => resetTrading.mutate(params)}
|
||||
isResetting={resetTrading.isPending}
|
||||
/>
|
||||
|
||||
@@ -490,26 +490,101 @@ function ApprovalRow({ approval, onReview }: {
|
||||
|
||||
|
||||
function ResetCard({ onReset, isResetting }: {
|
||||
onReset: () => void;
|
||||
onReset: (params: { initial_capital?: number; reserve_pct?: number }) => void;
|
||||
isResetting: boolean;
|
||||
}) {
|
||||
const [showConfirm, setShowConfirm] = useState(false);
|
||||
const [capitalInput, setCapitalInput] = useState('100000');
|
||||
const [reservePct, setReservePct] = useState(20);
|
||||
const [useCustomCapital, setUseCustomCapital] = useState(false);
|
||||
|
||||
const capital = parseFloat(capitalInput) || 0;
|
||||
const reserveAmount = capital * (reservePct / 100);
|
||||
const activeAmount = capital - reserveAmount;
|
||||
|
||||
return (
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Paper Trading Account</h2>
|
||||
|
||||
{/* Capital & Reserve Configuration */}
|
||||
<div className="mb-4 space-y-3 rounded-lg border border-surface-700 bg-surface-950 p-4">
|
||||
<div className="flex items-center gap-3">
|
||||
<button
|
||||
onClick={() => setUseCustomCapital(!useCustomCapital)}
|
||||
className={`relative inline-flex h-5 w-9 shrink-0 cursor-pointer rounded-full border-2 border-transparent transition-colors focus:outline-none focus:ring-2 focus:ring-brand-500 focus:ring-offset-2 focus:ring-offset-surface-900 ${
|
||||
useCustomCapital ? 'bg-brand-600' : 'bg-surface-700'
|
||||
}`}
|
||||
role="switch"
|
||||
aria-checked={useCustomCapital}
|
||||
aria-label="Set custom initial capital"
|
||||
>
|
||||
<span className={`pointer-events-none inline-block h-4 w-4 rounded-full bg-white shadow transition-transform ${
|
||||
useCustomCapital ? 'translate-x-4' : 'translate-x-0'
|
||||
}`} />
|
||||
</button>
|
||||
<span className="text-sm text-gray-300">Set initial capital</span>
|
||||
<span className="text-[10px] text-gray-600">(otherwise uses broker account balance)</span>
|
||||
</div>
|
||||
|
||||
{useCustomCapital && (
|
||||
<div className="flex items-center gap-2">
|
||||
<label htmlFor="reset-capital" className="text-xs text-gray-500">Capital $</label>
|
||||
<input
|
||||
id="reset-capital"
|
||||
type="number"
|
||||
min={0}
|
||||
step={1000}
|
||||
value={capitalInput}
|
||||
onChange={(e) => setCapitalInput(e.target.value)}
|
||||
className="w-36 rounded-md border border-surface-700 bg-surface-900 px-2 py-1 text-sm font-mono text-gray-200"
|
||||
/>
|
||||
</div>
|
||||
)}
|
||||
|
||||
<div>
|
||||
<div className="flex items-center justify-between">
|
||||
<label htmlFor="reset-reserve" className="text-xs text-gray-500">
|
||||
Reserve pool: {reservePct}%
|
||||
</label>
|
||||
<span className="text-xs text-gray-600">
|
||||
Active: {100 - reservePct}%
|
||||
</span>
|
||||
</div>
|
||||
<input
|
||||
id="reset-reserve"
|
||||
type="range"
|
||||
min={0}
|
||||
max={50}
|
||||
step={5}
|
||||
value={reservePct}
|
||||
onChange={(e) => setReservePct(Number(e.target.value))}
|
||||
className="mt-1 w-full accent-brand-600"
|
||||
/>
|
||||
{useCustomCapital && capital > 0 && (
|
||||
<div className="mt-1 flex justify-between text-[10px] text-gray-600">
|
||||
<span>Reserve: ${reserveAmount.toLocaleString(undefined, { maximumFractionDigits: 0 })}</span>
|
||||
<span>Active: ${activeAmount.toLocaleString(undefined, { maximumFractionDigits: 0 })}</span>
|
||||
</div>
|
||||
)}
|
||||
</div>
|
||||
</div>
|
||||
|
||||
{/* Reset Button */}
|
||||
<div className="flex items-center justify-between">
|
||||
<div>
|
||||
<p className="text-sm text-gray-300">Full Reset</p>
|
||||
<p className="text-[10px] text-gray-600">
|
||||
Liquidates all broker positions, cancels open orders, wipes local trading history,
|
||||
and syncs capital from the broker account.
|
||||
and sets capital from {useCustomCapital ? 'the amount above' : 'the broker account balance'}.
|
||||
</p>
|
||||
<p className="mt-1 text-[10px] text-gray-600 italic">
|
||||
Note: To reset the Alpaca paper account balance itself, use the Alpaca dashboard.
|
||||
</p>
|
||||
</div>
|
||||
<button
|
||||
onClick={() => setShowConfirm(true)}
|
||||
disabled={isResetting}
|
||||
className="rounded-md border border-red-700/50 bg-red-900/20 px-3 py-1.5 text-sm font-medium text-red-400 hover:bg-red-900/40 disabled:opacity-50"
|
||||
className="shrink-0 rounded-md border border-red-700/50 bg-red-900/20 px-3 py-1.5 text-sm font-medium text-red-400 hover:bg-red-900/40 disabled:opacity-50"
|
||||
>
|
||||
Reset Everything
|
||||
</button>
|
||||
@@ -519,11 +594,20 @@ function ResetCard({ onReset, isResetting }: {
|
||||
<p className="text-sm text-red-300">
|
||||
This will <span className="font-semibold">permanently delete</span> all positions, orders,
|
||||
trading decisions, stop levels, portfolio snapshots, and backtest data.
|
||||
All broker positions will be liquidated and capital will be set from the broker's account balance.
|
||||
All broker positions will be liquidated.
|
||||
{useCustomCapital
|
||||
? ` Capital will be set to $${capital.toLocaleString()} (${reservePct}% reserve / ${100 - reservePct}% active).`
|
||||
: ` Capital will be set from the broker's account balance (${reservePct}% reserve / ${100 - reservePct}% active).`}
|
||||
</p>
|
||||
<div className="mt-3 flex gap-2">
|
||||
<button
|
||||
onClick={() => { onReset(); setShowConfirm(false); }}
|
||||
onClick={() => {
|
||||
onReset({
|
||||
initial_capital: useCustomCapital ? capital : undefined,
|
||||
reserve_pct: reservePct / 100,
|
||||
});
|
||||
setShowConfirm(false);
|
||||
}}
|
||||
disabled={isResetting}
|
||||
className="rounded-md bg-red-600 px-3 py-1.5 text-sm font-medium text-white hover:bg-red-700 disabled:opacity-50"
|
||||
>
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
import { useState } from 'react';
|
||||
import { useState, useRef, useEffect } from 'react';
|
||||
import { useNavigate, Link } from '@tanstack/react-router';
|
||||
import { useTrends, useDocument } from '../api/hooks';
|
||||
import { TrendArrow, ConfidenceBar, LoadingSpinner, TickerFilter, Card } from '../components/ui';
|
||||
import { TrendArrow, ConfidenceBar, LoadingSpinner, Card } from '../components/ui';
|
||||
import type { TrendSummary } from '../api/hooks';
|
||||
|
||||
const WINDOWS = ['intraday', '1d', '7d', '30d', '90d'];
|
||||
@@ -9,8 +9,17 @@ const WINDOWS = ['intraday', '1d', '7d', '30d', '90d'];
|
||||
export function TrendsPage() {
|
||||
const navigate = useNavigate();
|
||||
const [ticker, setTicker] = useState('');
|
||||
const [debouncedTicker, setDebouncedTicker] = useState('');
|
||||
const [window, setWindow] = useState<string | undefined>(undefined);
|
||||
const { data, isLoading } = useTrends({ ticker: ticker || undefined, window, limit: 100 });
|
||||
const inputRef = useRef<HTMLInputElement>(null);
|
||||
|
||||
// Debounce ticker search — only query after 300ms of no typing
|
||||
useEffect(() => {
|
||||
const timer = setTimeout(() => setDebouncedTicker(ticker), 300);
|
||||
return () => clearTimeout(timer);
|
||||
}, [ticker]);
|
||||
|
||||
const { data, isLoading } = useTrends({ ticker: debouncedTicker || undefined, window, limit: 100 });
|
||||
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
|
||||
@@ -19,7 +28,15 @@ export function TrendsPage() {
|
||||
<div className="mb-4 flex items-center justify-between">
|
||||
<h1 className="text-xl font-semibold text-gray-100">Trends</h1>
|
||||
<div className="flex items-center gap-3">
|
||||
<TickerFilter value={ticker} onChange={setTicker} />
|
||||
<input
|
||||
ref={inputRef}
|
||||
type="text"
|
||||
placeholder="Ticker…"
|
||||
value={ticker}
|
||||
onChange={(e) => setTicker(e.target.value.toUpperCase())}
|
||||
className="w-24 rounded-md border border-surface-700 bg-surface-900 px-2 py-1 text-xs text-gray-200 placeholder-gray-500 focus:border-brand-500 focus:outline-none"
|
||||
aria-label="Filter by ticker"
|
||||
/>
|
||||
<div className="inline-flex rounded-md border border-surface-700" role="group" aria-label="Window selector">
|
||||
<button
|
||||
onClick={() => setWindow(undefined)}
|
||||
|
||||
@@ -35,6 +35,8 @@ export function TradingOverview() {
|
||||
const resume = useResumeTradingEngine();
|
||||
const updateConfig = useUpdateTradingConfig();
|
||||
const [selectedTier, setSelectedTier] = useState<string | null>(null);
|
||||
const [maxPositions, setMaxPositions] = useState<number | null>(null);
|
||||
const [positionCap, setPositionCap] = useState<number | null>(null);
|
||||
|
||||
if (isLoading) return <LoadingSpinner />;
|
||||
if (!status) return <p className="text-gray-500">No trading status available</p>;
|
||||
@@ -131,6 +133,68 @@ export function TradingOverview() {
|
||||
<StatCard label="Portfolio Heat" value={fmtPct(status.portfolio_heat)} />
|
||||
</div>
|
||||
|
||||
{/* Position Limits */}
|
||||
<Card>
|
||||
<h2 className="mb-3 text-sm font-medium text-gray-400">Position Limits</h2>
|
||||
<div className="grid grid-cols-1 gap-4 sm:grid-cols-2">
|
||||
<div>
|
||||
<label htmlFor="max-positions" className="block text-xs text-gray-500 mb-1">
|
||||
Max Open Positions
|
||||
</label>
|
||||
<div className="flex items-center gap-2">
|
||||
<input
|
||||
id="max-positions"
|
||||
type="number"
|
||||
min={1}
|
||||
max={50}
|
||||
value={maxPositions ?? status.max_open_positions ?? 10}
|
||||
onChange={(e) => setMaxPositions(Number(e.target.value))}
|
||||
className="w-20 rounded-md border border-surface-700 bg-surface-950 px-2 py-1.5 text-sm text-gray-200 focus:border-brand-500 focus:outline-none"
|
||||
/>
|
||||
<button
|
||||
onClick={() => {
|
||||
const val = maxPositions ?? status.max_open_positions ?? 10;
|
||||
updateConfig.mutate({ max_open_positions: val });
|
||||
}}
|
||||
disabled={updateConfig.isPending}
|
||||
className="rounded-md bg-brand-700 px-3 py-1.5 text-xs font-medium text-white hover:bg-brand-600 disabled:opacity-50"
|
||||
>
|
||||
Apply
|
||||
</button>
|
||||
<span className="text-xs text-gray-500">
|
||||
Current: {status.open_position_count ?? 0} / {status.max_open_positions ?? 10}
|
||||
</span>
|
||||
</div>
|
||||
</div>
|
||||
<div>
|
||||
<label htmlFor="position-cap" className="block text-xs text-gray-500 mb-1">
|
||||
Absolute Position Cap ($)
|
||||
</label>
|
||||
<div className="flex items-center gap-2">
|
||||
<input
|
||||
id="position-cap"
|
||||
type="number"
|
||||
min={10}
|
||||
step={10}
|
||||
value={positionCap ?? status.absolute_position_cap ?? 50}
|
||||
onChange={(e) => setPositionCap(Number(e.target.value))}
|
||||
className="w-24 rounded-md border border-surface-700 bg-surface-950 px-2 py-1.5 text-sm text-gray-200 focus:border-brand-500 focus:outline-none"
|
||||
/>
|
||||
<button
|
||||
onClick={() => {
|
||||
const val = positionCap ?? status.absolute_position_cap ?? 50;
|
||||
updateConfig.mutate({ absolute_position_cap: val });
|
||||
}}
|
||||
disabled={updateConfig.isPending}
|
||||
className="rounded-md bg-brand-700 px-3 py-1.5 text-xs font-medium text-white hover:bg-brand-600 disabled:opacity-50"
|
||||
>
|
||||
Apply
|
||||
</button>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
</Card>
|
||||
|
||||
{/* Portfolio Heat Gauge */}
|
||||
<Card>
|
||||
<h2 className="mb-2 text-sm font-medium text-gray-400">Portfolio Heat</h2>
|
||||
|
||||
@@ -30,6 +30,8 @@ import { HomePage } from './pages/Home';
|
||||
import { GlobalEventsPage } from './pages/GlobalEvents';
|
||||
import { GlobalEventDetailPage } from './pages/GlobalEventDetail';
|
||||
import { AgentsPage } from './pages/Agents';
|
||||
import { ReportsPage } from './pages/Reports';
|
||||
import { ReportDetailPage } from './pages/ReportDetail';
|
||||
|
||||
// Root route wraps everything in the app shell layout
|
||||
const rootRoute = createRootRoute({
|
||||
@@ -167,6 +169,17 @@ const agentsRoute = createRoute({
|
||||
component: AgentsPage,
|
||||
});
|
||||
|
||||
const reportsRoute = createRoute({
|
||||
getParentRoute: () => rootRoute,
|
||||
path: '/reports',
|
||||
component: ReportsPage,
|
||||
});
|
||||
const reportDetailRoute = createRoute({
|
||||
getParentRoute: () => rootRoute,
|
||||
path: '/reports/$id',
|
||||
component: ReportDetailPage,
|
||||
});
|
||||
|
||||
const routeTree = rootRoute.addChildren([
|
||||
indexRoute,
|
||||
companiesRoute,
|
||||
@@ -192,6 +205,8 @@ const routeTree = rootRoute.addChildren([
|
||||
globalEventsRoute,
|
||||
globalEventDetailRoute,
|
||||
agentsRoute,
|
||||
reportsRoute,
|
||||
reportDetailRoute,
|
||||
]);
|
||||
|
||||
export const router = createRouter({ routeTree });
|
||||
|
||||
@@ -73,6 +73,97 @@ export const mockVariantPerfHistory = [
|
||||
{ hour: '2026-04-10T11:00:00Z', invocations: 12, successes: 11, avg_duration_ms: 1300, avg_confidence: 0.82 },
|
||||
];
|
||||
|
||||
// Validation: Model Quality & Calibration mock data
|
||||
export const mockValidationSummary = {
|
||||
snapshot: {
|
||||
id: 'ms-1',
|
||||
generated_at: '2026-04-11T12:00:00Z',
|
||||
lookback_window: '30d',
|
||||
horizon: '7d',
|
||||
prediction_count: 150,
|
||||
win_rate: 0.58,
|
||||
directional_accuracy: 0.56,
|
||||
information_coefficient: 0.045,
|
||||
rank_information_coefficient: 0.038,
|
||||
avg_return: 0.012,
|
||||
avg_excess_return_vs_spy: 0.003,
|
||||
avg_excess_return_vs_sector: 0.002,
|
||||
calibration_error: 0.08,
|
||||
brier_score: 0.21,
|
||||
buy_win_rate: 0.61,
|
||||
sell_win_rate: 0.54,
|
||||
hold_win_rate: 0.50,
|
||||
metadata: {},
|
||||
},
|
||||
gate_status: {
|
||||
passed: true,
|
||||
reason: 'all thresholds met',
|
||||
threshold_results: [
|
||||
{ name: 'min_prediction_count', threshold: 100, actual: 150, passed: true },
|
||||
{ name: 'min_ic', threshold: 0.03, actual: 0.045, passed: true },
|
||||
{ name: 'min_win_rate', threshold: 0.53, actual: 0.58, passed: true },
|
||||
],
|
||||
},
|
||||
};
|
||||
|
||||
export const mockValidationCalibration = {
|
||||
buckets: [
|
||||
{ bucket_low: 0.50, bucket_high: 0.60, avg_confidence: 0.55, observed_win_rate: 0.52, prediction_count: 30, miscalibrated: false },
|
||||
{ bucket_low: 0.60, bucket_high: 0.70, avg_confidence: 0.65, observed_win_rate: 0.58, prediction_count: 40, miscalibrated: false },
|
||||
{ bucket_low: 0.70, bucket_high: 0.80, avg_confidence: 0.75, observed_win_rate: 0.55, prediction_count: 35, miscalibrated: true },
|
||||
{ bucket_low: 0.80, bucket_high: 0.90, avg_confidence: 0.85, observed_win_rate: 0.70, prediction_count: 25, miscalibrated: false },
|
||||
{ bucket_low: 0.90, bucket_high: 1.00, avg_confidence: 0.95, observed_win_rate: 0.72, prediction_count: 20, miscalibrated: true },
|
||||
],
|
||||
lookback: '30d',
|
||||
horizon: '7d',
|
||||
};
|
||||
|
||||
export const mockValidationGateStatus = {
|
||||
gate_status: {
|
||||
passed: false,
|
||||
reason: 'failed: min_ic below threshold',
|
||||
threshold_results: [
|
||||
{ name: 'min_prediction_count', threshold: 100, actual: 150, passed: true },
|
||||
{ name: 'min_ic', threshold: 0.03, actual: 0.02, passed: false },
|
||||
{ name: 'min_win_rate', threshold: 0.53, actual: 0.58, passed: true },
|
||||
],
|
||||
},
|
||||
};
|
||||
|
||||
export const mockValidationICByHorizon = {
|
||||
horizons: [
|
||||
{ horizon: '1h', information_coefficient: 0.02, rank_information_coefficient: 0.015, prediction_count: 120, generated_at: '2026-04-11T12:00:00Z' },
|
||||
{ horizon: '7d', information_coefficient: 0.045, rank_information_coefficient: 0.038, prediction_count: 100, generated_at: '2026-04-11T12:00:00Z' },
|
||||
],
|
||||
lookback: '30d',
|
||||
};
|
||||
|
||||
export const mockValidationAttributionSources = {
|
||||
sources: [
|
||||
{ source: 'Reuters', source_type: 'news_api', prediction_count: 50, avg_weight: 0.6, avg_contribution_score: 0.3, win_rate: 0.62, avg_future_return: 0.015, avg_excess_return_vs_spy: 0.005, information_coefficient: 0.05, duplicate_rate: 0.1 },
|
||||
],
|
||||
lookback: '30d',
|
||||
horizon: '7d',
|
||||
};
|
||||
|
||||
export const mockValidationAttributionCatalysts = {
|
||||
catalysts: [
|
||||
{ catalyst_type: 'earnings', prediction_count: 40, win_rate: 0.65, avg_future_return: 0.02, avg_excess_return_vs_spy: 0.008, information_coefficient: 0.06 },
|
||||
],
|
||||
lookback: '30d',
|
||||
horizon: '7d',
|
||||
};
|
||||
|
||||
export const mockValidationAttributionLayers = {
|
||||
layers: [
|
||||
{ layer: 'company', avg_contribution_pct: 0.55, dominant_win_rate: 0.60, dominant_ic: 0.04 },
|
||||
{ layer: 'macro', avg_contribution_pct: 0.30, dominant_win_rate: 0.52, dominant_ic: 0.02 },
|
||||
{ layer: 'competitive', avg_contribution_pct: 0.15, dominant_win_rate: 0.48, dominant_ic: null },
|
||||
],
|
||||
lookback: '30d',
|
||||
horizon: '7d',
|
||||
};
|
||||
|
||||
export const handlers = [
|
||||
// Query API (proxied at /api/)
|
||||
http.get('/api/companies', () => HttpResponse.json(mockCompanies)),
|
||||
@@ -242,4 +333,24 @@ export const handlers = [
|
||||
const body = await request.json() as Record<string, unknown>;
|
||||
return HttpResponse.json({ enabled: body.enabled, previous_enabled: true, toggled_by: 'operator' });
|
||||
}),
|
||||
|
||||
// Trading Reports
|
||||
http.get('/api/reports', () => HttpResponse.json([
|
||||
{ id: 'rpt-1', report_type: 'daily', period_start: '2025-01-15', period_end: '2025-01-15', validation_status: 'passed', generated_at: '2025-01-15T21:30:00Z' },
|
||||
])),
|
||||
http.get('/api/reports/:id', ({ params }) => {
|
||||
if (params.id === 'rpt-1') {
|
||||
return HttpResponse.json({ id: 'rpt-1', report_type: 'daily', period_start: '2025-01-15', period_end: '2025-01-15', report_data: { pnl: { realized_pnl: 125.5 }, executive_summary: 'Test' }, validation_status: 'passed', generated_at: '2025-01-15T21:30:00Z', created_at: '2025-01-15T21:30:05Z' });
|
||||
}
|
||||
return new HttpResponse(null, { status: 404 });
|
||||
}),
|
||||
|
||||
// Validation: Model Quality & Calibration endpoints
|
||||
http.get('/api/validation/summary', () => HttpResponse.json(mockValidationSummary)),
|
||||
http.get('/api/validation/calibration', () => HttpResponse.json(mockValidationCalibration)),
|
||||
http.get('/api/validation/gate-status', () => HttpResponse.json(mockValidationGateStatus)),
|
||||
http.get('/api/validation/ic-by-horizon', () => HttpResponse.json(mockValidationICByHorizon)),
|
||||
http.get('/api/validation/attribution/sources', () => HttpResponse.json(mockValidationAttributionSources)),
|
||||
http.get('/api/validation/attribution/catalysts', () => HttpResponse.json(mockValidationAttributionCatalysts)),
|
||||
http.get('/api/validation/attribution/layers', () => HttpResponse.json(mockValidationAttributionLayers)),
|
||||
];
|
||||
|
||||
@@ -169,6 +169,55 @@ describe('Global Events page', () => {
|
||||
});
|
||||
});
|
||||
|
||||
describe('OpsModel validation tab', () => {
|
||||
it('renders Model Validation tab with summary cards', async () => {
|
||||
renderRoute('/ops/model');
|
||||
await waitFor(() => expect(screen.getByText('Model Performance')).toBeInTheDocument());
|
||||
|
||||
// The tab buttons should be present
|
||||
expect(screen.getByText('Extraction Performance')).toBeInTheDocument();
|
||||
expect(screen.getByText('Model Validation')).toBeInTheDocument();
|
||||
|
||||
// Click the Model Validation tab button
|
||||
await userEvent.click(screen.getByText('Model Validation'));
|
||||
|
||||
// Summary cards should render key metric labels unique to the validation summary
|
||||
await waitFor(() => {
|
||||
expect(screen.getByText('Brier Score')).toBeInTheDocument();
|
||||
expect(screen.getByText('ECE')).toBeInTheDocument();
|
||||
expect(screen.getByText('Directional Accuracy')).toBeInTheDocument();
|
||||
expect(screen.getByText('Excess vs SPY')).toBeInTheDocument();
|
||||
});
|
||||
}, 10000);
|
||||
|
||||
it('renders calibration table with miscalibration warning', async () => {
|
||||
renderRoute('/ops/model');
|
||||
await waitFor(() => expect(screen.getByText('Model Performance')).toBeInTheDocument());
|
||||
|
||||
await userEvent.click(screen.getByText('Model Validation'));
|
||||
|
||||
await waitFor(() => {
|
||||
expect(screen.getByText('Calibration by Confidence Bucket')).toBeInTheDocument();
|
||||
});
|
||||
|
||||
// Miscalibrated buckets should show warning text
|
||||
const miscalWarnings = screen.getAllByText('Miscalibrated');
|
||||
expect(miscalWarnings.length).toBeGreaterThanOrEqual(1);
|
||||
}, 10000);
|
||||
|
||||
it('renders gate status pass/fail indicator', async () => {
|
||||
renderRoute('/ops/model');
|
||||
await waitFor(() => expect(screen.getByText('Model Performance')).toBeInTheDocument());
|
||||
|
||||
await userEvent.click(screen.getByText('Model Validation'));
|
||||
|
||||
// The gate-status endpoint returns passed: false
|
||||
await waitFor(() => {
|
||||
expect(screen.getByText(/Live Trading Gate: FAIL/)).toBeInTheDocument();
|
||||
});
|
||||
}, 10000);
|
||||
});
|
||||
|
||||
describe('Agents page', () => {
|
||||
it('renders agent list in sidebar', async () => {
|
||||
renderRoute('/agents');
|
||||
|
||||
@@ -0,0 +1,155 @@
|
||||
/**
|
||||
* Frontend hook tests for trading reports.
|
||||
*
|
||||
* Tests useReports and useReport hooks with MSW mocks.
|
||||
* Requirements validated: 5.4, 5.5
|
||||
*/
|
||||
import { renderHook, waitFor } from '@testing-library/react';
|
||||
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
|
||||
import { http, HttpResponse } from 'msw';
|
||||
import { type ReactNode, createElement } from 'react';
|
||||
import { describe, expect, it } from 'vitest';
|
||||
import { useReports, useReport } from '../api/hooks';
|
||||
import { server } from './mocks/server';
|
||||
|
||||
const mockReportList = [
|
||||
{
|
||||
id: 'rpt-1',
|
||||
report_type: 'daily',
|
||||
period_start: '2025-01-15',
|
||||
period_end: '2025-01-15',
|
||||
validation_status: 'passed',
|
||||
generated_at: '2025-01-15T21:30:00Z',
|
||||
},
|
||||
{
|
||||
id: 'rpt-2',
|
||||
report_type: 'weekly',
|
||||
period_start: '2025-01-13',
|
||||
period_end: '2025-01-17',
|
||||
validation_status: 'warnings',
|
||||
generated_at: '2025-01-18T10:00:00Z',
|
||||
},
|
||||
];
|
||||
|
||||
const mockReportDetail = {
|
||||
id: 'rpt-1',
|
||||
report_type: 'daily',
|
||||
period_start: '2025-01-15',
|
||||
period_end: '2025-01-15',
|
||||
validation_status: 'passed',
|
||||
generated_at: '2025-01-15T21:30:00Z',
|
||||
created_at: '2025-01-15T21:30:05Z',
|
||||
report_data: {
|
||||
pnl: { realized_pnl: 125.5, unrealized_pnl: -30.2 },
|
||||
executive_summary: 'Test executive summary',
|
||||
},
|
||||
};
|
||||
|
||||
function createWrapper() {
|
||||
const queryClient = new QueryClient({
|
||||
defaultOptions: {
|
||||
queries: { retry: false, gcTime: 0 },
|
||||
},
|
||||
});
|
||||
return function Wrapper({ children }: { children: ReactNode }) {
|
||||
return createElement(QueryClientProvider, { client: queryClient }, children);
|
||||
};
|
||||
}
|
||||
|
||||
describe('useReports', () => {
|
||||
it('fetches report list with default params', async () => {
|
||||
server.use(
|
||||
http.get('/api/reports', () => HttpResponse.json(mockReportList)),
|
||||
);
|
||||
|
||||
const { result } = renderHook(() => useReports(), {
|
||||
wrapper: createWrapper(),
|
||||
});
|
||||
|
||||
await waitFor(() => expect(result.current.isSuccess).toBe(true));
|
||||
|
||||
expect(result.current.data).toHaveLength(2);
|
||||
expect(result.current.data![0].id).toBe('rpt-1');
|
||||
expect(result.current.data![0].report_type).toBe('daily');
|
||||
expect(result.current.data![1].report_type).toBe('weekly');
|
||||
});
|
||||
|
||||
it('passes query params for filtering', async () => {
|
||||
let capturedUrl = '';
|
||||
server.use(
|
||||
http.get('/api/reports', ({ request }) => {
|
||||
capturedUrl = request.url;
|
||||
return HttpResponse.json([mockReportList[0]]);
|
||||
}),
|
||||
);
|
||||
|
||||
const { result } = renderHook(
|
||||
() => useReports({ report_type: 'daily', limit: 10 }),
|
||||
{ wrapper: createWrapper() },
|
||||
);
|
||||
|
||||
await waitFor(() => expect(result.current.isSuccess).toBe(true));
|
||||
|
||||
expect(capturedUrl).toContain('report_type=daily');
|
||||
expect(capturedUrl).toContain('limit=10');
|
||||
expect(result.current.data).toHaveLength(1);
|
||||
});
|
||||
|
||||
it('handles error state', async () => {
|
||||
server.use(
|
||||
http.get('/api/reports', () =>
|
||||
new HttpResponse(null, { status: 500 }),
|
||||
),
|
||||
);
|
||||
|
||||
const { result } = renderHook(() => useReports(), {
|
||||
wrapper: createWrapper(),
|
||||
});
|
||||
|
||||
await waitFor(() => expect(result.current.isError).toBe(true));
|
||||
});
|
||||
});
|
||||
|
||||
describe('useReport', () => {
|
||||
it('fetches single report by id', async () => {
|
||||
server.use(
|
||||
http.get('/api/reports/rpt-1', () =>
|
||||
HttpResponse.json(mockReportDetail),
|
||||
),
|
||||
);
|
||||
|
||||
const { result } = renderHook(() => useReport('rpt-1'), {
|
||||
wrapper: createWrapper(),
|
||||
});
|
||||
|
||||
await waitFor(() => expect(result.current.isSuccess).toBe(true));
|
||||
|
||||
expect(result.current.data!.id).toBe('rpt-1');
|
||||
expect(result.current.data!.report_data).toBeDefined();
|
||||
expect(result.current.data!.report_data.pnl).toBeDefined();
|
||||
expect(result.current.data!.created_at).toBe('2025-01-15T21:30:05Z');
|
||||
});
|
||||
|
||||
it('does not fetch when id is undefined', async () => {
|
||||
const { result } = renderHook(() => useReport(undefined), {
|
||||
wrapper: createWrapper(),
|
||||
});
|
||||
|
||||
// Should stay in idle/loading state without fetching
|
||||
expect(result.current.isFetching).toBe(false);
|
||||
});
|
||||
|
||||
it('handles 404 error', async () => {
|
||||
server.use(
|
||||
http.get('/api/reports/nonexistent', () =>
|
||||
new HttpResponse(null, { status: 404 }),
|
||||
),
|
||||
);
|
||||
|
||||
const { result } = renderHook(() => useReport('nonexistent'), {
|
||||
wrapper: createWrapper(),
|
||||
});
|
||||
|
||||
await waitFor(() => expect(result.current.isError).toBe(true));
|
||||
});
|
||||
});
|
||||
@@ -90,6 +90,25 @@ spec:
|
||||
volumeMounts:
|
||||
- name: tmp
|
||||
mountPath: /tmp
|
||||
- name: backfill-market-data
|
||||
image: {{ $root.Values.image.registry }}/{{ $svc.image }}:{{ $root.Values.image.tag }}
|
||||
imagePullPolicy: {{ $root.Values.image.pullPolicy }}
|
||||
command: ["sh", "-c", "python /app/scripts/backfill_market_data.py 2>/dev/null || echo 'Backfill script not available — skipping'"]
|
||||
securityContext:
|
||||
{{- include "stonks.containerSecurityContext" $root | nindent 12 }}
|
||||
envFrom:
|
||||
- configMapRef:
|
||||
name: stonks-config
|
||||
{{- range $svc.secrets }}
|
||||
- secretRef:
|
||||
name: {{ . }}
|
||||
{{- end }}
|
||||
resources:
|
||||
requests: { cpu: 50m, memory: 64Mi }
|
||||
limits: { cpu: 200m, memory: 256Mi }
|
||||
volumeMounts:
|
||||
- name: tmp
|
||||
mountPath: /tmp
|
||||
{{- end }}
|
||||
containers:
|
||||
- name: {{ $svc.image }}
|
||||
|
||||
@@ -0,0 +1,108 @@
|
||||
{{- if .Values.specialist }}
|
||||
{{- if .Values.specialist.enabled }}
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: specialist
|
||||
namespace: {{ .Release.Namespace }}
|
||||
labels:
|
||||
app: specialist
|
||||
{{- include "stonks.labels" . | nindent 4 }}
|
||||
stonks-oracle/tier: processing
|
||||
spec:
|
||||
replicas: {{ .Values.specialist.replicas | default 2 }}
|
||||
selector:
|
||||
matchLabels:
|
||||
app: specialist
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: specialist
|
||||
stonks-oracle/tier: processing
|
||||
spec:
|
||||
automountServiceAccountToken: false
|
||||
{{- with .Values.imagePullSecrets }}
|
||||
imagePullSecrets:
|
||||
{{- toYaml . | nindent 8 }}
|
||||
{{- end }}
|
||||
securityContext:
|
||||
{{- include "stonks.podSecurityContext" . | nindent 8 }}
|
||||
containers:
|
||||
- name: specialist
|
||||
image: {{ .Values.image.registry }}/specialist:{{ .Values.image.tag }}
|
||||
imagePullPolicy: {{ .Values.image.pullPolicy }}
|
||||
command: ["sh", "-c", "uvicorn services.specialist.app:app --host 0.0.0.0 --port 8000"]
|
||||
ports:
|
||||
- containerPort: 8000
|
||||
env:
|
||||
- name: SPECIALIST_MODEL
|
||||
value: {{ .Values.specialist.model | default "urchade/gliner_large-v2.1" | quote }}
|
||||
- name: SPECIALIST_MAX_BATCH_SIZE
|
||||
value: {{ .Values.specialist.maxBatchSize | default "32" | quote }}
|
||||
- name: SPECIALIST_MAX_WAIT_MS
|
||||
value: {{ .Values.specialist.maxWaitMs | default "50.0" | quote }}
|
||||
- name: SPECIALIST_MAX_QUEUE_SIZE
|
||||
value: {{ .Values.specialist.maxQueueSize | default "256" | quote }}
|
||||
- name: SPECIALIST_TEST_MODE
|
||||
value: {{ .Values.specialist.testMode | default "0" | quote }}
|
||||
securityContext:
|
||||
{{- include "stonks.containerSecurityContext" . | nindent 12 }}
|
||||
envFrom:
|
||||
- configMapRef:
|
||||
name: stonks-config
|
||||
{{- range .Values.specialist.secrets }}
|
||||
- secretRef:
|
||||
name: {{ . }}
|
||||
{{- end }}
|
||||
resources:
|
||||
requests:
|
||||
cpu: {{ .Values.specialist.resources.requests.cpu | default "2" | quote }}
|
||||
memory: {{ .Values.specialist.resources.requests.memory | default "4Gi" }}
|
||||
limits:
|
||||
cpu: {{ .Values.specialist.resources.limits.cpu | default "6" | quote }}
|
||||
memory: {{ .Values.specialist.resources.limits.memory | default "10Gi" }}
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: /ready
|
||||
port: 8000
|
||||
initialDelaySeconds: 10
|
||||
periodSeconds: 10
|
||||
timeoutSeconds: 5
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /health
|
||||
port: 8000
|
||||
initialDelaySeconds: 30
|
||||
periodSeconds: 30
|
||||
timeoutSeconds: 5
|
||||
volumeMounts:
|
||||
- name: tmp
|
||||
mountPath: /tmp
|
||||
- name: model-cache
|
||||
mountPath: /root/.cache
|
||||
volumes:
|
||||
- name: tmp
|
||||
emptyDir:
|
||||
sizeLimit: 10Mi
|
||||
- name: model-cache
|
||||
emptyDir:
|
||||
sizeLimit: 5Gi
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: specialist
|
||||
namespace: {{ .Release.Namespace }}
|
||||
labels:
|
||||
app: specialist
|
||||
{{- include "stonks.labels" . | nindent 4 }}
|
||||
spec:
|
||||
selector:
|
||||
app: specialist
|
||||
ports:
|
||||
- port: 8000
|
||||
targetPort: 8000
|
||||
protocol: TCP
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
@@ -17,6 +17,8 @@ services:
|
||||
replicas: 1
|
||||
dashboard:
|
||||
replicas: 1
|
||||
signalEngine:
|
||||
replicas: 0
|
||||
|
||||
## Beta-specific config overrides
|
||||
## Beta shares the paper DB — DEPLOY_STAGE=beta isolates Redis keys
|
||||
@@ -26,8 +28,7 @@ config:
|
||||
DEPLOY_STAGE: "beta"
|
||||
LOG_LEVEL: "DEBUG"
|
||||
JSON_LOGS: "true"
|
||||
# Disable actual trading in beta — safety net
|
||||
TRADING_ENABLED: "false"
|
||||
TRADING_ENABLED: "true"
|
||||
# Use same infra services (shared postgres/redis/minio)
|
||||
POSTGRES_HOST: "postgresql-rw.postgresql-service.svc.cluster.local"
|
||||
POSTGRES_PORT: "5432"
|
||||
@@ -40,10 +41,10 @@ config:
|
||||
MINIO_SECURE: "false"
|
||||
BROKER_MODE: "paper"
|
||||
BROKER_PROVIDER: "alpaca"
|
||||
OLLAMA_BASE_URL: "http://192.168.42.254:11434"
|
||||
OLLAMA_MODEL: "qwen3.6"
|
||||
VLLM_BASE_URL: "http://192.168.42.254:8000"
|
||||
VLLM_MODEL: "AxionML/Qwen3.5-9B-NVFP4"
|
||||
OLLAMA_BASE_URL: "http://nuextract-external.vllm-service.svc.cluster.local:2701"
|
||||
OLLAMA_MODEL: "numind/NuExtract3"
|
||||
VLLM_BASE_URL: "http://nuextract-external.vllm-service.svc.cluster.local:2701"
|
||||
VLLM_MODEL: "numind/NuExtract3"
|
||||
VLLM_TIMEOUT: "120"
|
||||
VLLM_MAX_RETRIES: "2"
|
||||
VLLM_TEMPERATURE: "0.7"
|
||||
@@ -59,10 +60,10 @@ secrets:
|
||||
POSTGRES_PASSWORD: "St0nks0racl3!"
|
||||
MINIO_ACCESS_KEY: "AKIA6V7J3N9B5P0D2YQH"
|
||||
MINIO_SECRET_KEY: "8fG3!v2rJ7$wN@9mLpQ6zXbC4tKdPqW1"
|
||||
REDIS_PASSWORD: "PSCh4ng3me!"
|
||||
REDIS_PASSWORD: "SGaIkaf342Ljym7jChmqPY7i"
|
||||
broker:
|
||||
BROKER_API_KEY: "PKEQXRJUTQCXJYLB4QOQC2LE6"
|
||||
BROKER_API_SECRET: "Df1ZKL6d7F83CDM1jaFDh3K4BxQZJY9VoymoFvEaWiij"
|
||||
BROKER_API_KEY: "PK2SC5XYTYOXZZ7JZDZZPG3JMD"
|
||||
BROKER_API_SECRET: "3kpUW5Wz7bjLVnbdygeN24NNoHtvK4d1bQKwNg53SPZw"
|
||||
BROKER_BASE_URL: "https://paper-api.alpaca.markets"
|
||||
market:
|
||||
MARKET_DATA_API_KEY: "NPwKtrLvoBxcKt3Byp5PEvuZiBZU_d8E"
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
## Live-Math stage overrides
|
||||
## Helm merges these with the base values.yaml.
|
||||
## Runs the dual-pipeline signal engine with its own paper trading account
|
||||
## for validating the math-upgraded signal pipeline in production conditions.
|
||||
|
||||
## Image tag — overridden by Kargo during promotion
|
||||
image:
|
||||
tag: latest
|
||||
|
||||
## Config overrides: paper broker (separate account), dedicated DB/Redis namespace
|
||||
config:
|
||||
BROKER_MODE: "paper"
|
||||
BROKER_PROVIDER: "alpaca"
|
||||
LOG_LEVEL: "INFO"
|
||||
TRADING_ENABLED: "true"
|
||||
POSTGRES_DB: "stonks_live_math"
|
||||
REDIS_DB: "3"
|
||||
DEPLOY_STAGE: "live-math"
|
||||
POSTGRES_USER: "stonks_live_math"
|
||||
OLLAMA_BASE_URL: "http://10.1.1.12:2701"
|
||||
MARKET_DATA_BASE_URL: "https://api.polygon.io"
|
||||
|
||||
## Secrets — dedicated paper trading account for live-math
|
||||
secrets:
|
||||
core:
|
||||
POSTGRES_PASSWORD: "St0nks0racl3!"
|
||||
MINIO_ACCESS_KEY: "AKIA6V7J3N9B5P0D2YQH"
|
||||
MINIO_SECRET_KEY: "8fG3!v2rJ7$wN@9mLpQ6zXbC4tKdPqW1"
|
||||
REDIS_PASSWORD: "SGaIkaf342Ljym7jChmqPY7i"
|
||||
broker:
|
||||
BROKER_API_KEY: "PK64RS7NH24XPBI3IDEU3BB72Y"
|
||||
BROKER_API_SECRET: "Ho4D84392vB4s2TkGi52ra5FcxEskGfJSZYRKHa3qrYq"
|
||||
BROKER_BASE_URL: "https://paper-api.alpaca.markets"
|
||||
market:
|
||||
MARKET_DATA_API_KEY: "NPwKtrLvoBxcKt3Byp5PEvuZiBZU_d8E"
|
||||
|
||||
## Live-math-specific ingress hostnames
|
||||
ingress:
|
||||
hosts:
|
||||
queryApi: stonks-math-api.celestium.life
|
||||
symbolRegistry: stonks-math-registry.celestium.life
|
||||
dashboard: stonks-math.celestium.life
|
||||
superset: stonks-math-dash.celestium.life
|
||||
trino: stonks-math-trino.celestium.life
|
||||
tradingEngine: stonks-math-trading.celestium.life
|
||||
|
||||
## Scale: same as production (single replicas for most services)
|
||||
services:
|
||||
extractor:
|
||||
replicas: 1
|
||||
@@ -16,7 +16,10 @@ config:
|
||||
REDIS_DB: "2"
|
||||
DEPLOY_STAGE: "paper"
|
||||
POSTGRES_USER: "stonks_paper"
|
||||
OLLAMA_BASE_URL: "http://10.1.1.12:2701"
|
||||
OLLAMA_BASE_URL: "http://nuextract-external.vllm-service.svc.cluster.local:2701"
|
||||
OLLAMA_MODEL: "numind/NuExtract3"
|
||||
VLLM_BASE_URL: "http://nuextract-external.vllm-service.svc.cluster.local:2701"
|
||||
VLLM_MODEL: "numind/NuExtract3"
|
||||
MARKET_DATA_BASE_URL: "https://api.polygon.io"
|
||||
|
||||
## Secrets — all credentials for the paper stage
|
||||
@@ -27,7 +30,7 @@ secrets:
|
||||
POSTGRES_PASSWORD: "St0nks0racl3!"
|
||||
MINIO_ACCESS_KEY: "AKIA6V7J3N9B5P0D2YQH"
|
||||
MINIO_SECRET_KEY: "8fG3!v2rJ7$wN@9mLpQ6zXbC4tKdPqW1"
|
||||
REDIS_PASSWORD: "PSCh4ng3me!"
|
||||
REDIS_PASSWORD: "SGaIkaf342Ljym7jChmqPY7i"
|
||||
broker:
|
||||
BROKER_API_KEY: "PKECQBNHD6ZLKEXZZVIFTOLX72"
|
||||
BROKER_API_SECRET: "5pV8zfUn92zAUL4TAwFor3Lk8RqNBcRzN12Y1HJjU7Gn"
|
||||
@@ -49,3 +52,5 @@ ingress:
|
||||
services:
|
||||
extractor:
|
||||
replicas: 1
|
||||
signalEngine:
|
||||
replicas: 0
|
||||
|
||||
@@ -19,8 +19,8 @@ services:
|
||||
tier: orchestration
|
||||
secrets: [stonks-core-secrets]
|
||||
resources:
|
||||
requests: { cpu: 50m, memory: 64Mi }
|
||||
limits: { cpu: 200m, memory: 128Mi }
|
||||
requests: { cpu: 50m, memory: 128Mi }
|
||||
limits: { cpu: 200m, memory: 256Mi }
|
||||
|
||||
symbolRegistry:
|
||||
replicas: 1
|
||||
@@ -37,7 +37,7 @@ services:
|
||||
liveness: { path: /docs, port: 8000, initialDelay: 10, period: 30 }
|
||||
|
||||
ingestion:
|
||||
replicas: 2
|
||||
replicas: 1
|
||||
pipeline: true
|
||||
image: ingestion
|
||||
command: "python -m services.ingestion.worker"
|
||||
@@ -99,8 +99,8 @@ services:
|
||||
port: 8000
|
||||
secrets: [stonks-core-secrets, stonks-broker-secrets, stonks-gmail-secrets]
|
||||
resources:
|
||||
requests: { cpu: 100m, memory: 256Mi }
|
||||
limits: { cpu: 500m, memory: 512Mi }
|
||||
requests: { cpu: 100m, memory: 512Mi }
|
||||
limits: { cpu: 1000m, memory: 1024Mi }
|
||||
probes:
|
||||
readiness: { path: /ready, port: 8000, initialDelay: 5, period: 10 }
|
||||
liveness: { path: /health, port: 8000, initialDelay: 10, period: 30 }
|
||||
@@ -127,8 +127,19 @@ services:
|
||||
requests: { cpu: 50m, memory: 64Mi }
|
||||
limits: { cpu: 200m, memory: 128Mi }
|
||||
|
||||
signalEngine:
|
||||
replicas: 0
|
||||
pipeline: true
|
||||
image: signal-engine
|
||||
command: "python -m services.signal_engine.main"
|
||||
tier: processing
|
||||
secrets: [stonks-core-secrets, stonks-market-secrets]
|
||||
resources:
|
||||
requests: { cpu: 100m, memory: 128Mi }
|
||||
limits: { cpu: 500m, memory: 256Mi }
|
||||
|
||||
lakePublisher:
|
||||
replicas: 1
|
||||
replicas: 0
|
||||
pipeline: true
|
||||
image: lake-publisher
|
||||
command: "python -m services.lake_publisher.jobs"
|
||||
@@ -144,7 +155,7 @@ services:
|
||||
command: "uvicorn services.api.app:app --host 0.0.0.0 --port 8000"
|
||||
tier: api
|
||||
port: 8000
|
||||
secrets: [stonks-core-secrets]
|
||||
secrets: [stonks-core-secrets, stonks-market-secrets]
|
||||
resources:
|
||||
requests: { cpu: 100m, memory: 128Mi }
|
||||
limits: { cpu: 500m, memory: 256Mi }
|
||||
@@ -174,15 +185,15 @@ config:
|
||||
REDIS_DB: "0"
|
||||
MINIO_ENDPOINT: "minio.minio-service.svc.cluster.local:80"
|
||||
MINIO_SECURE: "false"
|
||||
OLLAMA_BASE_URL: ""
|
||||
OLLAMA_MODEL: "qwen3.5:9b-fast"
|
||||
OLLAMA_BASE_URL: "http://nuextract-external.vllm-service.svc.cluster.local:2701"
|
||||
OLLAMA_MODEL: "numind/NuExtract3"
|
||||
OLLAMA_TIMEOUT: "240"
|
||||
OLLAMA_MAX_RETRIES: "2"
|
||||
OLLAMA_RETRY_BASE_DELAY: "1.0"
|
||||
OLLAMA_RETRY_MAX_DELAY: "10.0"
|
||||
OLLAMA_RETRY_BACKOFF_MULTIPLIER: "2.0"
|
||||
VLLM_BASE_URL: "http://192.168.42.254:8000"
|
||||
VLLM_MODEL: "AxionML/Qwen3.5-9B-NVFP4"
|
||||
VLLM_BASE_URL: "http://nuextract-external.vllm-service.svc.cluster.local:2701"
|
||||
VLLM_MODEL: "numind/NuExtract3"
|
||||
VLLM_TIMEOUT: "120"
|
||||
VLLM_MAX_RETRIES: "2"
|
||||
VLLM_TEMPERATURE: "0.7"
|
||||
@@ -194,7 +205,7 @@ config:
|
||||
TRINO_ICEBERG_CATALOG: "iceberg"
|
||||
BROKER_MODE: "paper"
|
||||
BROKER_PROVIDER: ""
|
||||
MARKET_DATA_BASE_URL: ""
|
||||
MARKET_DATA_BASE_URL: "https://api.polygon.io"
|
||||
MARKET_DATA_PROVIDER: "polygon"
|
||||
RETENTION_RAW_MARKET_DAYS: "90"
|
||||
RETENTION_RAW_NEWS_DAYS: "180"
|
||||
@@ -221,20 +232,21 @@ config:
|
||||
TRADING_RISK_TIER: "moderate"
|
||||
TRADING_ABSOLUTE_POSITION_CAP: "10000.0"
|
||||
TRADING_MAX_OPEN_POSITIONS: "10"
|
||||
TZ: "America/Los_Angeles"
|
||||
|
||||
## Secrets
|
||||
secrets:
|
||||
core:
|
||||
POSTGRES_PASSWORD: ""
|
||||
MINIO_ACCESS_KEY: ""
|
||||
MINIO_SECRET_KEY: ""
|
||||
REDIS_PASSWORD: ""
|
||||
POSTGRES_PASSWORD: "St0nks0racl3!"
|
||||
MINIO_ACCESS_KEY: "AKIA6V7J3N9B5P0D2YQH"
|
||||
MINIO_SECRET_KEY: "8fG3!v2rJ7$wN@9mLpQ6zXbC4tKdPqW1"
|
||||
REDIS_PASSWORD: "SGaIkaf342Ljym7jChmqPY7i"
|
||||
broker:
|
||||
BROKER_API_KEY: ""
|
||||
BROKER_API_SECRET: ""
|
||||
BROKER_BASE_URL: ""
|
||||
BROKER_API_KEY: "PKECQBNHD6ZLKEXZZVIFTOLX72"
|
||||
BROKER_API_SECRET: "5pV8zfUn92zAUL4TAwFor3Lk8RqNBcRzN12Y1HJjU7Gn"
|
||||
BROKER_BASE_URL: "https://paper-api.alpaca.markets"
|
||||
market:
|
||||
MARKET_DATA_API_KEY: ""
|
||||
MARKET_DATA_API_KEY: "NPwKtrLvoBxcKt3Byp5PEvuZiBZU_d8E"
|
||||
gmail:
|
||||
GMAIL_SENDER: "celes@celestium.life"
|
||||
GMAIL_RECIPIENT: "celes@celestium.life"
|
||||
@@ -277,6 +289,24 @@ superset:
|
||||
requests: { cpu: 200m, memory: 512Mi }
|
||||
limits: { cpu: "1", memory: 2Gi }
|
||||
|
||||
## Specialist inference service (CPU-first NER/classification)
|
||||
specialist:
|
||||
enabled: true
|
||||
replicas: 2
|
||||
model: "urchade/gliner_large-v2.1"
|
||||
maxBatchSize: "32"
|
||||
maxWaitMs: "50.0"
|
||||
maxQueueSize: "256"
|
||||
testMode: "0"
|
||||
secrets: [stonks-core-secrets]
|
||||
resources:
|
||||
requests:
|
||||
cpu: "2"
|
||||
memory: 4Gi
|
||||
limits:
|
||||
cpu: "6"
|
||||
memory: 10Gi
|
||||
|
||||
## Network policies
|
||||
networkPolicies:
|
||||
enabled: true
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: vllm
|
||||
namespace: vllm-service
|
||||
labels:
|
||||
app: vllm
|
||||
spec:
|
||||
replicas: 1
|
||||
strategy:
|
||||
type: Recreate
|
||||
selector:
|
||||
matchLabels:
|
||||
app: vllm
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: vllm
|
||||
spec:
|
||||
runtimeClassName: nvidia
|
||||
enableServiceLinks: false
|
||||
nodeSelector:
|
||||
kubernetes.io/hostname: gremlin-1
|
||||
containers:
|
||||
- name: vllm
|
||||
image: registry.celestium.life/stonks-oracle/vllm-openai:latest
|
||||
imagePullPolicy: Always
|
||||
args:
|
||||
- "--model"
|
||||
- "numind/NuExtract3"
|
||||
- "--served-model-name"
|
||||
- "numind/NuExtract3"
|
||||
- "--host"
|
||||
- "0.0.0.0"
|
||||
- "--port"
|
||||
- "8000"
|
||||
- "--gpu-memory-utilization"
|
||||
- "0.80"
|
||||
- "--max-model-len"
|
||||
- "8192"
|
||||
- "--max-num-seqs"
|
||||
- "8"
|
||||
env:
|
||||
- name: HF_TOKEN
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: vllm-secrets
|
||||
key: HF_TOKEN
|
||||
- name: VLLM_ATTENTION_BACKEND
|
||||
value: "FLASHINFER"
|
||||
ports:
|
||||
- containerPort: 8000
|
||||
name: http
|
||||
resources:
|
||||
limits:
|
||||
nvidia.com/gpu: "1"
|
||||
requests:
|
||||
cpu: "2"
|
||||
memory: "8Gi"
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: /health
|
||||
port: 8000
|
||||
initialDelaySeconds: 120
|
||||
periodSeconds: 10
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /health
|
||||
port: 8000
|
||||
initialDelaySeconds: 300
|
||||
periodSeconds: 30
|
||||
volumeMounts:
|
||||
- name: hf-cache
|
||||
mountPath: /root/.cache/huggingface
|
||||
volumes:
|
||||
- name: hf-cache
|
||||
persistentVolumeClaim:
|
||||
claimName: vllm-hf-cache-pvc
|
||||
@@ -0,0 +1,93 @@
|
||||
#!/usr/bin/env bash
|
||||
VLLM="http://10.1.1.12:31508"
|
||||
GPU_HOST="root@10.1.1.12"
|
||||
INTERVAL=3
|
||||
|
||||
while true; do
|
||||
clear
|
||||
echo "═══════════════════════════════════════════════════════════════"
|
||||
echo " vLLM MONITOR (K8s) $(date '+%Y-%m-%d %H:%M:%S')"
|
||||
echo "═══════════════════════════════════════════════════════════════"
|
||||
|
||||
# GPU
|
||||
gpu=$(ssh -o ConnectTimeout=2 -o BatchMode=yes "$GPU_HOST" \
|
||||
'nvidia-smi --query-gpu=name,temperature.gpu,power.draw,power.limit,memory.used,memory.total,utilization.gpu --format=csv,noheader,nounits' 2>/dev/null)
|
||||
if [ -n "$gpu" ]; then
|
||||
IFS=',' read -r name temp power power_cap mem_used mem_total gpu_util <<< "$gpu"
|
||||
mem_free=$(awk "BEGIN{printf \"%.0f\", $mem_total-$mem_used}")
|
||||
echo ""
|
||||
echo " GPU: ${name}"
|
||||
echo " ├─ Temp: ${temp}°C Power: ${power}W / ${power_cap}W"
|
||||
echo " ├─ VRAM: ${mem_used} / ${mem_total} MiB (${mem_free} MiB free)"
|
||||
echo " └─ Util: ${gpu_util}%"
|
||||
fi
|
||||
|
||||
# vLLM model info
|
||||
models_json=$(curl -sf --max-time 2 "$VLLM/v1/models" 2>/dev/null)
|
||||
if [ -n "$models_json" ]; then
|
||||
echo ""
|
||||
python3 -c "
|
||||
import json,sys
|
||||
data = json.loads(sys.argv[1])
|
||||
for m in data.get('data',[]):
|
||||
print(f' MODEL: {m[\"id\"]}')
|
||||
" "$models_json" 2>/dev/null
|
||||
fi
|
||||
|
||||
# Prometheus metrics from vLLM /metrics endpoint
|
||||
prom=$(curl -sf --max-time 2 "$VLLM/metrics" 2>/dev/null)
|
||||
if [ -n "$prom" ]; then
|
||||
python3 -c "
|
||||
import sys
|
||||
lines = sys.argv[1].split('\n')
|
||||
def gauge(prefix):
|
||||
for l in lines:
|
||||
if l.startswith(prefix) and not l.startswith('#'):
|
||||
return float(l.split()[-1])
|
||||
return 0
|
||||
def counter(prefix):
|
||||
return sum(float(l.split()[-1]) for l in lines if l.startswith(prefix) and not l.startswith('#'))
|
||||
def histo_avg(prefix):
|
||||
s = counter(prefix + '_sum')
|
||||
c = counter(prefix + '_count')
|
||||
return s/c if c > 0 else 0
|
||||
|
||||
running = gauge('vllm:num_requests_running')
|
||||
waiting = gauge('vllm:num_requests_waiting')
|
||||
kv_pct = gauge('vllm:gpu_cache_usage_perc') * 100
|
||||
prompt_tok = counter('vllm:prompt_tokens_total')
|
||||
gen_tok = counter('vllm:generation_tokens_total')
|
||||
req_ok = counter('vllm:request_success_total')
|
||||
preempts = counter('vllm:num_preemptions_total')
|
||||
|
||||
ttft = histo_avg('vllm:time_to_first_token_seconds')
|
||||
itl = histo_avg('vllm:inter_token_latency_seconds')
|
||||
e2e = histo_avg('vllm:e2e_request_latency_seconds')
|
||||
tok_s = 1/itl if itl > 0 else 0
|
||||
|
||||
print()
|
||||
print(' REQUESTS:')
|
||||
print(f' ├─ Running: {int(running)} Waiting: {int(waiting)}')
|
||||
print(f' ├─ Completed: {int(req_ok)} Preemptions: {int(preempts)}')
|
||||
print(f' └─ KV Cache: {kv_pct:.1f}%')
|
||||
print()
|
||||
print(' TOKENS:')
|
||||
print(f' ├─ Prompt: {int(prompt_tok):,}')
|
||||
print(f' └─ Generated: {int(gen_tok):,}')
|
||||
print()
|
||||
print(' LATENCY:')
|
||||
print(f' ├─ TTFT: {ttft*1000:.0f}ms')
|
||||
print(f' ├─ ITL: {itl*1000:.1f}ms')
|
||||
print(f' ├─ Tok/s: {tok_s:.1f}')
|
||||
print(f' └─ E2E avg: {e2e:.2f}s')
|
||||
" "$prom" 2>/dev/null
|
||||
else
|
||||
echo ""
|
||||
echo " METRICS: unreachable"
|
||||
fi
|
||||
|
||||
echo ""
|
||||
echo "═══════════════════════════════════════════════════════════════"
|
||||
echo " Ctrl+C to exit"
|
||||
sleep "$INTERVAL"
|
||||
done
|
||||
@@ -0,0 +1,29 @@
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: nuextract
|
||||
namespace: vllm-service
|
||||
spec:
|
||||
ports:
|
||||
- name: http
|
||||
port: 8000
|
||||
targetPort: 8000
|
||||
selector:
|
||||
app: vllm
|
||||
type: ClusterIP
|
||||
---
|
||||
# External access via NodePort (like ollama's port 2701 pattern)
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: nuextract-external
|
||||
namespace: vllm-service
|
||||
spec:
|
||||
ports:
|
||||
- nodePort: 31508
|
||||
name: vllm-api
|
||||
port: 2701
|
||||
targetPort: 8080
|
||||
selector:
|
||||
app: vllm-metrics
|
||||
type: LoadBalancer
|
||||
@@ -0,0 +1,35 @@
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: vllm-hf-cache-pv
|
||||
spec:
|
||||
capacity:
|
||||
storage: 50Gi
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
persistentVolumeReclaimPolicy: Retain
|
||||
storageClassName: local-path
|
||||
hostPath:
|
||||
path: /var/lib/vllm/hf-cache
|
||||
type: DirectoryOrCreate
|
||||
nodeAffinity:
|
||||
required:
|
||||
nodeSelectorTerms:
|
||||
- matchExpressions:
|
||||
- key: kubernetes.io/hostname
|
||||
operator: In
|
||||
values:
|
||||
- gremlin-1
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: vllm-hf-cache-pvc
|
||||
namespace: vllm-service
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 50Gi
|
||||
storageClassName: local-path
|
||||
@@ -0,0 +1,45 @@
|
||||
replicaCount: 1
|
||||
|
||||
image:
|
||||
repository: vllm/vllm-openai
|
||||
tag: latest
|
||||
pullPolicy: Always
|
||||
|
||||
resources:
|
||||
limits:
|
||||
nvidia.com/gpu: 1
|
||||
requests:
|
||||
cpu: "2"
|
||||
memory: "8Gi"
|
||||
|
||||
runtimeClassName: nvidia
|
||||
|
||||
env:
|
||||
- name: HF_TOKEN
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: vllm-secrets
|
||||
key: HF_TOKEN
|
||||
|
||||
args:
|
||||
- "serve"
|
||||
- "numind/NuExtract3"
|
||||
- "--served-model-name"
|
||||
- "numind/NuExtract3"
|
||||
- "--host"
|
||||
- "0.0.0.0"
|
||||
- "--port"
|
||||
- "8000"
|
||||
- "--gpu-memory-utilization"
|
||||
- "0.45"
|
||||
- "--max-model-len"
|
||||
- "8192"
|
||||
- "--max-num-seqs"
|
||||
- "8"
|
||||
|
||||
service:
|
||||
type: ClusterIP
|
||||
port: 8000
|
||||
|
||||
nodeSelector:
|
||||
kubernetes.io/hostname: gremlin-1
|
||||
@@ -0,0 +1,74 @@
|
||||
# vLLM metrics proxy — similar to ollama-metrics
|
||||
# Proxies requests and exposes Prometheus metrics
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: vllm-metrics
|
||||
namespace: vllm-service
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: vllm-metrics
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: vllm-metrics
|
||||
spec:
|
||||
containers:
|
||||
- name: proxy
|
||||
image: nginx:alpine
|
||||
ports:
|
||||
- containerPort: 8080
|
||||
volumeMounts:
|
||||
- name: nginx-conf
|
||||
mountPath: /etc/nginx/conf.d/default.conf
|
||||
subPath: default.conf
|
||||
volumes:
|
||||
- name: nginx-conf
|
||||
configMap:
|
||||
name: vllm-proxy-config
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: vllm-proxy-config
|
||||
namespace: vllm-service
|
||||
data:
|
||||
default.conf: |
|
||||
upstream vllm_backend {
|
||||
server nuextract.vllm-service.svc.cluster.local:8000;
|
||||
}
|
||||
|
||||
server {
|
||||
listen 8080;
|
||||
|
||||
# API proxy
|
||||
location / {
|
||||
proxy_pass http://vllm_backend;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_connect_timeout 300s;
|
||||
proxy_read_timeout 300s;
|
||||
proxy_send_timeout 300s;
|
||||
}
|
||||
|
||||
# vLLM exposes /metrics natively
|
||||
location /metrics {
|
||||
proxy_pass http://vllm_backend/metrics;
|
||||
}
|
||||
}
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: vllm-metrics
|
||||
namespace: vllm-service
|
||||
spec:
|
||||
ports:
|
||||
- name: proxy
|
||||
port: 8080
|
||||
targetPort: 8080
|
||||
selector:
|
||||
app: vllm-metrics
|
||||
type: ClusterIP
|
||||
@@ -8,7 +8,7 @@ CREATE TABLE IF NOT EXISTS ai_agents (
|
||||
slug VARCHAR(100) NOT NULL UNIQUE,
|
||||
purpose TEXT NOT NULL DEFAULT '',
|
||||
model_provider VARCHAR(50) NOT NULL DEFAULT 'ollama',
|
||||
model_name VARCHAR(200) NOT NULL DEFAULT 'qwen3.5:9b',
|
||||
model_name VARCHAR(200) NOT NULL DEFAULT 'qwen3.5:9b-fast',
|
||||
system_prompt TEXT NOT NULL DEFAULT '',
|
||||
user_prompt_template TEXT NOT NULL DEFAULT '',
|
||||
prompt_version VARCHAR(100) NOT NULL DEFAULT '',
|
||||
|
||||
@@ -1,22 +1,23 @@
|
||||
-- Sync ai_agents system_prompt and model_name to match code defaults.
|
||||
-- The original 026 seed used abbreviated prompts and the base model name;
|
||||
-- this migration brings them in line with the authoritative prompts defined
|
||||
-- in the Python service code and the actual deployed model tag.
|
||||
-- Sync ai_agents system_prompt to match code defaults.
|
||||
-- The original 026 seed used abbreviated prompts; this migration brings
|
||||
-- them in line with the authoritative prompts defined in the Python
|
||||
-- service code.
|
||||
--
|
||||
-- NOTE: model_name and model_provider are NOT overwritten here.
|
||||
-- They are configured per-environment via the API or direct DB update
|
||||
-- and should not be reset by migrations.
|
||||
|
||||
UPDATE ai_agents
|
||||
SET system_prompt = E'You are a financial document analyst. Extract structured data as JSON. Return ONLY a single JSON object. No markdown fences, no explanation, no text before or after the JSON. Every field in the schema is required. Use "other" for catalyst_type if unsure. Keep evidence_spans short (under 20 words each). Keep key_facts to 3-5 items max.',
|
||||
model_name = 'qwen3.5:9b-fast',
|
||||
updated_at = NOW()
|
||||
WHERE slug = 'document-extractor';
|
||||
|
||||
UPDATE ai_agents
|
||||
SET system_prompt = E'You classify MACRO-LEVEL global news into structured event JSON. Return ONLY a single JSON object. No markdown, no explanation. Every field is required. Keep key_facts to 3-5 items. Keep summary under 3 sentences.\n\nCRITICAL: Only classify articles about MACRO events that affect entire markets, sectors, or economies. Examples: trade wars, interest rate changes, commodity supply disruptions, regulatory changes, geopolitical conflicts, natural disasters.\n\nDO NOT classify as macro events: individual company earnings, lawsuits against a single company, single-company management changes, individual stock analysis, company-specific debt or bankruptcy, product launches by one company. For these, set severity to "low", confidence below 0.3, and leave affected_regions, affected_sectors, and affected_commodities as empty arrays.',
|
||||
model_name = 'qwen3.5:9b-fast',
|
||||
updated_at = NOW()
|
||||
WHERE slug = 'event-classifier';
|
||||
|
||||
UPDATE ai_agents
|
||||
SET system_prompt = E'You are a concise financial analyst. You rewrite structured trade thesis summaries into clear, professional prose suitable for an internal research note.\n\nSTRICT RULES:\n1. Do NOT add any information that is not present in the input.\n2. Do NOT fabricate numbers, dates, company names, or analyst opinions.\n3. Keep the rewrite under 150 words.\n4. Preserve all factual claims, risk notes, and evidence counts from the input.\n5. Use a neutral, professional tone. Avoid hype or marketing language.\n6. Return ONLY the rewritten thesis text. No JSON, no markdown, no commentary.',
|
||||
model_name = 'qwen3.5:9b-fast',
|
||||
updated_at = NOW()
|
||||
WHERE slug = 'thesis-rewriter';
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
-- Fix agent default model_provider and model_name to match production config.
|
||||
-- The original migration 026 seeded with 'ollama'/'qwen3.5:9b-fast' but production
|
||||
-- uses vLLM. This migration updates agents that still have the old defaults,
|
||||
-- preserving any user customizations (only updates if model_name matches the old default).
|
||||
|
||||
UPDATE ai_agents
|
||||
SET model_provider = 'vllm',
|
||||
model_name = 'AxionML/Qwen3.5-9B-NVFP4',
|
||||
max_tokens = 2048,
|
||||
updated_at = NOW()
|
||||
WHERE slug IN ('document-extractor', 'event-classifier', 'thesis-rewriter')
|
||||
AND source = 'system'
|
||||
AND model_name = 'qwen3.5:9b-fast';
|
||||
@@ -0,0 +1,15 @@
|
||||
-- Fix max_tokens default: 32768 is the full context window, not a reasonable
|
||||
-- output limit. vLLM rejects requests where max_tokens >= context_window
|
||||
-- because there's no room left for the input prompt.
|
||||
--
|
||||
-- Change the column default to 4096 (sufficient for structured JSON extraction
|
||||
-- output) and update any existing rows still at the old default.
|
||||
|
||||
ALTER TABLE ai_agents ALTER COLUMN max_tokens SET DEFAULT 4096;
|
||||
ALTER TABLE agent_variants ALTER COLUMN max_tokens SET DEFAULT 4096;
|
||||
|
||||
UPDATE ai_agents SET max_tokens = 4096, updated_at = NOW()
|
||||
WHERE max_tokens = 32768;
|
||||
|
||||
UPDATE agent_variants SET max_tokens = 4096
|
||||
WHERE max_tokens = 32768;
|
||||
@@ -0,0 +1,12 @@
|
||||
-- Seed a default risk_configs row with all signal layers explicitly enabled.
|
||||
-- This ensures fresh deployments have macro and competitive layers active
|
||||
-- without requiring manual API calls or DB patches.
|
||||
-- Idempotent: skips if an active config already exists.
|
||||
|
||||
INSERT INTO risk_configs (name, trading_mode, config, active)
|
||||
SELECT 'default', 'paper',
|
||||
'{"macro_enabled": true, "competitive_enabled": true}'::jsonb,
|
||||
TRUE
|
||||
WHERE NOT EXISTS (
|
||||
SELECT 1 FROM risk_configs WHERE active = TRUE
|
||||
);
|
||||
@@ -0,0 +1,16 @@
|
||||
-- Stop hardcoding agent model_name in migrations.
|
||||
--
|
||||
-- Migration 029 previously forced model_name='qwen3.5:9b-fast' on every
|
||||
-- deploy, overwriting per-environment model configuration. That migration
|
||||
-- has been fixed to only sync system_prompt (not model_name).
|
||||
--
|
||||
-- This migration updates agents still on the old ollama provider/model
|
||||
-- to use vllm with the default VLLM model. Agents already configured
|
||||
-- with a different model (e.g. via the API) are left untouched.
|
||||
|
||||
UPDATE ai_agents
|
||||
SET model_provider = 'vllm',
|
||||
model_name = 'AxionML/Qwen3.5-9B-NVFP4',
|
||||
updated_at = NOW()
|
||||
WHERE model_name IN ('qwen3.5:9b-fast', 'qwen3.5:9b')
|
||||
AND source = 'system';
|
||||
@@ -0,0 +1,18 @@
|
||||
-- Source accuracy tracking table for historical prediction accuracy per source.
|
||||
--
|
||||
-- Stores per-source accuracy metrics (fraction of correct directional calls)
|
||||
-- used by the probabilistic scoring pipeline to weight source credibility.
|
||||
-- See Requirement 4.5: source accuracy metrics stored with source identifier,
|
||||
-- accuracy ratio, sample count, and last updated timestamp.
|
||||
|
||||
CREATE TABLE IF NOT EXISTS source_accuracy (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
source_id VARCHAR(200) NOT NULL,
|
||||
accuracy_ratio FLOAT NOT NULL DEFAULT 0.5,
|
||||
sample_count INTEGER NOT NULL DEFAULT 0,
|
||||
last_updated TIMESTAMPTZ NOT NULL DEFAULT NOW(),
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
|
||||
UNIQUE(source_id)
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_source_accuracy_source ON source_accuracy(source_id);
|
||||
@@ -0,0 +1,176 @@
|
||||
-- Migration 035: Model Validation, Calibration, and Signal Quality
|
||||
-- Creates tables for prediction snapshots, outcomes, evidence links, and metric snapshots
|
||||
-- Plus views for prediction performance and source performance analysis
|
||||
|
||||
-- ============================================================================
|
||||
-- Table: prediction_snapshots
|
||||
-- Immutable snapshot of a prediction at generation time
|
||||
-- ============================================================================
|
||||
CREATE TABLE IF NOT EXISTS prediction_snapshots (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
generated_at TIMESTAMPTZ NOT NULL,
|
||||
ticker VARCHAR(20) NOT NULL,
|
||||
"window" VARCHAR(20) NOT NULL,
|
||||
horizon VARCHAR(50) NOT NULL,
|
||||
direction VARCHAR(20) NOT NULL,
|
||||
action VARCHAR(20) NOT NULL,
|
||||
mode VARCHAR(50) NOT NULL,
|
||||
strength FLOAT NOT NULL,
|
||||
confidence FLOAT NOT NULL,
|
||||
contradiction FLOAT NOT NULL DEFAULT 0.0,
|
||||
p_bull FLOAT,
|
||||
p_bear FLOAT,
|
||||
score_company FLOAT NOT NULL DEFAULT 0.0,
|
||||
score_macro FLOAT NOT NULL DEFAULT 0.0,
|
||||
score_competitive FLOAT NOT NULL DEFAULT 0.0,
|
||||
evidence_count INTEGER NOT NULL DEFAULT 0,
|
||||
unique_source_count INTEGER NOT NULL DEFAULT 0,
|
||||
duplicate_evidence_count INTEGER NOT NULL DEFAULT 0,
|
||||
price_at_prediction FLOAT,
|
||||
spy_price_at_prediction FLOAT,
|
||||
sector_etf_price_at_prediction FLOAT,
|
||||
metadata JSONB DEFAULT '{}',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_snap_ticker ON prediction_snapshots(ticker);
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_snap_generated ON prediction_snapshots(generated_at);
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_snap_horizon ON prediction_snapshots(horizon);
|
||||
|
||||
-- ============================================================================
|
||||
-- Table: prediction_outcomes
|
||||
-- Realized outcome for a prediction at a specific horizon
|
||||
-- ============================================================================
|
||||
CREATE TABLE IF NOT EXISTS prediction_outcomes (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
prediction_id UUID NOT NULL REFERENCES prediction_snapshots(id),
|
||||
evaluated_at TIMESTAMPTZ NOT NULL,
|
||||
horizon VARCHAR(20) NOT NULL,
|
||||
future_price FLOAT,
|
||||
future_return FLOAT,
|
||||
spy_future_price FLOAT,
|
||||
spy_return FLOAT,
|
||||
sector_etf_future_price FLOAT,
|
||||
sector_etf_return FLOAT,
|
||||
excess_return_vs_spy FLOAT,
|
||||
excess_return_vs_sector FLOAT,
|
||||
direction_correct BOOLEAN,
|
||||
profitable BOOLEAN,
|
||||
metadata JSONB DEFAULT '{}',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_out_prediction ON prediction_outcomes(prediction_id);
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_out_horizon ON prediction_outcomes(horizon);
|
||||
CREATE INDEX IF NOT EXISTS idx_pred_out_evaluated ON prediction_outcomes(evaluated_at);
|
||||
|
||||
-- ============================================================================
|
||||
-- Table: signal_evidence_links
|
||||
-- Link between a prediction and a contributing evidence document
|
||||
-- ============================================================================
|
||||
CREATE TABLE IF NOT EXISTS signal_evidence_links (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
prediction_id UUID NOT NULL REFERENCES prediction_snapshots(id),
|
||||
document_id VARCHAR(200),
|
||||
signal_id VARCHAR(200),
|
||||
ticker VARCHAR(20),
|
||||
source VARCHAR(200),
|
||||
source_type VARCHAR(50),
|
||||
catalyst_type VARCHAR(50),
|
||||
sentiment VARCHAR(20),
|
||||
impact FLOAT,
|
||||
extraction_confidence FLOAT,
|
||||
weight FLOAT,
|
||||
is_duplicate BOOLEAN NOT NULL DEFAULT FALSE,
|
||||
canonical_evidence_key VARCHAR(64),
|
||||
contribution_score FLOAT,
|
||||
metadata JSONB DEFAULT '{}',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_sig_ev_prediction ON signal_evidence_links(prediction_id);
|
||||
CREATE INDEX IF NOT EXISTS idx_sig_ev_document ON signal_evidence_links(document_id);
|
||||
CREATE INDEX IF NOT EXISTS idx_sig_ev_ticker ON signal_evidence_links(ticker);
|
||||
|
||||
-- ============================================================================
|
||||
-- Table: model_metric_snapshots
|
||||
-- Aggregate model quality metrics for a lookback/horizon combination
|
||||
-- ============================================================================
|
||||
CREATE TABLE IF NOT EXISTS model_metric_snapshots (
|
||||
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
|
||||
generated_at TIMESTAMPTZ NOT NULL,
|
||||
lookback_window VARCHAR(20) NOT NULL,
|
||||
horizon VARCHAR(20) NOT NULL,
|
||||
prediction_count INTEGER NOT NULL DEFAULT 0,
|
||||
win_rate FLOAT,
|
||||
directional_accuracy FLOAT,
|
||||
information_coefficient FLOAT,
|
||||
rank_information_coefficient FLOAT,
|
||||
avg_return FLOAT,
|
||||
avg_excess_return_vs_spy FLOAT,
|
||||
avg_excess_return_vs_sector FLOAT,
|
||||
calibration_error FLOAT,
|
||||
brier_score FLOAT,
|
||||
buy_win_rate FLOAT,
|
||||
sell_win_rate FLOAT,
|
||||
hold_win_rate FLOAT,
|
||||
metadata JSONB DEFAULT '{}',
|
||||
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
|
||||
);
|
||||
|
||||
CREATE INDEX IF NOT EXISTS idx_model_snap_generated ON model_metric_snapshots(generated_at);
|
||||
CREATE INDEX IF NOT EXISTS idx_model_snap_lookback ON model_metric_snapshots(lookback_window);
|
||||
CREATE INDEX IF NOT EXISTS idx_model_snap_horizon ON model_metric_snapshots(horizon);
|
||||
|
||||
-- ============================================================================
|
||||
-- View: v_prediction_performance
|
||||
-- Joins prediction snapshots with outcomes for flat analysis
|
||||
-- ============================================================================
|
||||
CREATE OR REPLACE VIEW v_prediction_performance AS
|
||||
SELECT
|
||||
ps.ticker,
|
||||
ps.direction,
|
||||
ps.action,
|
||||
ps.confidence,
|
||||
ps.strength,
|
||||
ps.contradiction,
|
||||
ps.p_bull,
|
||||
ps.score_company,
|
||||
ps.score_macro,
|
||||
ps.score_competitive,
|
||||
ps.evidence_count,
|
||||
ps.unique_source_count,
|
||||
ps.duplicate_evidence_count,
|
||||
ps.price_at_prediction,
|
||||
po.future_return,
|
||||
po.excess_return_vs_spy,
|
||||
po.excess_return_vs_sector,
|
||||
po.direction_correct,
|
||||
po.profitable,
|
||||
po.horizon,
|
||||
ps.generated_at,
|
||||
po.evaluated_at
|
||||
FROM prediction_snapshots ps
|
||||
JOIN prediction_outcomes po ON po.prediction_id = ps.id;
|
||||
|
||||
-- ============================================================================
|
||||
-- View: v_source_performance
|
||||
-- Joins evidence links with snapshots and outcomes for source attribution
|
||||
-- ============================================================================
|
||||
CREATE OR REPLACE VIEW v_source_performance AS
|
||||
SELECT
|
||||
sel.source,
|
||||
sel.source_type,
|
||||
sel.catalyst_type,
|
||||
sel.sentiment,
|
||||
sel.weight,
|
||||
sel.contribution_score,
|
||||
sel.is_duplicate,
|
||||
po.direction_correct,
|
||||
po.future_return,
|
||||
po.excess_return_vs_spy,
|
||||
po.horizon,
|
||||
ps.generated_at
|
||||
FROM signal_evidence_links sel
|
||||
JOIN prediction_snapshots ps ON ps.id = sel.prediction_id
|
||||
JOIN prediction_outcomes po ON po.prediction_id = sel.prediction_id;
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user