OmniAlpha

OmniAlpha is a research-first AI quantitative trading platform designed to turn market hypotheses into measurable, reproducible decisions before any capital is put at risk. Its intended product direction is a research-and-paper-trading workspace for independent researchers and small research teams.

The problem and business value

Quantitative research often loses trust at the handoff between data, strategy, risk, and execution. OmniAlpha makes those handoffs explicit: data carries lineage, indicators and backtests remain deterministic, risk is a first-class decision, and paper execution is the safety boundary. The business value is a more auditable research process that can show what was believed, what evidence supported it, how costs and limits affected the result, and what changed in the next iteration.

The repository does not claim market returns, predictive alpha, production uptime, customer adoption, or investment outcomes.

What it does today

The current repository is a TypeScript monorepo with shared domain contracts, deterministic research libraries, service boundaries, agent protocols, Supabase migrations, and local validation workflows.

Demonstrably implemented and covered by repository tests are:

• Pure technical indicators with explicit warm-up behavior.
• A deterministic, long-only backtesting engine with fees, slippage, turnover, participation and liquidity limits, drawdown and win-rate metrics, cost-sensitivity helpers, strict time semantics, walk-forward windows, and an out-of-sample evaluation hook.
• A provider-independent risk gate that checks notional, exposure, loss, freshness, participation, concentration, and versioned signal evidence before it emits a paper-order intent.
• A deterministic paper ledger with accepted, partial, filled, cancelled, retry, duplicate, and reconciliation behavior.
• A paper-only broker boundary with typed transient failures, idempotent client order IDs, cancellation, reconciliation, and a kill-switch check.
• AI-assisted agent run persistence with prompt revisions, bounded confidence, evidence links, approval state, redaction checks, replay metadata, and human promotion gates.
• A server-only read API contract and a framework-neutral dashboard read model that preserves loading, empty, stale, and error states instead of inventing values.

These are tested contracts and local behaviors, not a claim that the entire product is deployed or ready for live users.

Integrations and data flow

The intended flow is:

provider data → normalization and quality checks → versioned dataset evidence
      → indicators and strategy research → cost-aware backtests
      → risk decision → paper ledger or sandbox paper adapter → analytics
      ↘ news and macro context → AI-assisted evidence review

Supabase Postgres is the transactional system of record for normalized observations, dataset lineage, strategies, backtest runs, signals, paper state, risk decisions, and agent runs. Versioned migrations define workspace membership and row-level security boundaries. Large raw or derived artifacts have a storage contract, but a production object-storage adapter is still pending.

Market-data ingestion is provider-agnostic. The repository includes normalization, manifest, lineage, and quality contracts plus redaction-safe GET-only coverage probes for Tiingo and Massive. The documented probes provide observed coverage evidence for sampled windows, but the results remain pending review for entitlements, licensing, adjustment policy, gaps, retention, and approved storage. No raw licensed dataset is promoted to training, backtesting, or redistribution by this repository state.

Alpaca Paper and IBKR Paper are candidate sandbox integrations behind the broker boundary; neither is presented as a connected production integration. Provider approval, account authorization, sandbox credentials, and end-to-end testing are still required.

AI or automation workflow

AI agents coordinate research context, hypotheses, and evidence summaries. They are AI-assisted: each run records its role, scope, prompt revision, cited evidence, confidence, output, and approval state. Deterministic indicators, backtests, risk checks, and paper execution remain outside the agent's authority.

Human review is required before research or paper configuration is promoted. The repository contains prompt evaluation and replay contracts, but it does not implement autonomous live trading or an opaque automatic decision path.

The operational automation currently consists of bounded local workflows such as provider-coverage probing, delivery dry runs, prompt evaluations, and package-level checks. No GitHub Actions or production scheduler is configured in the bootstrap.

Collaboration and notification flow

The collaboration model is workspace- and role-oriented: authenticated members can read research and paper evidence according to row-level security, while paper-capable roles are required for paper-state writes and independent reviewers are required for promotion decisions.

There is no outbound email, chat, or notification provider integrated in the current repository. The collaboration contract is the recorded research, risk, paper, and agent evidence trail rather than an automatic AI chat assistant or a broker alerting product.

Security/privacy boundaries

The source repository is private and this brief intentionally excludes source code, credentials, environment values, private URLs, account identifiers, raw provider payloads, customer data, and internal logs. Server-side database access is separated from browser access; public database roles remain closed until the authenticated API model is deliberately expanded. Workspace data is tenant-scoped through Supabase RLS, agent payloads reject secret-bearing fields, and observability events redact secret-like values.

The local database seed is synthetic development data, not a licensed market-data archive. The project is not licensed for redistribution or commercial use by default; any future customer-facing data workflow requires separate entitlement, licensing, retention, privacy, and security review.

What is coming next

The next product steps are evidence-gated rather than a promise of live trading:

• Freeze an approved, versioned provider dataset manifest and normalize only manifest-approved data.
• Validate one paper broker sandbox adapter with authorization, failure, retry, duplicate, cancellation, reconciliation, and kill-switch evidence.
• Turn the framework-neutral dashboard model into an authenticated browser workflow for manifests, data quality, reports, and paper state, with explicit stale and failure states.
• Add approved artifact storage, restore and retention evidence, operational observability, and measured load/recovery evidence.
• Consider a small, invitation-only product-discovery pilot for research and paper workflows only, after provider, browser, storage, authenticated-user, cost, and customer-interview gates are satisfied.

Live broker execution, automated capital allocation, and return claims remain outside the current product boundary and would require a new architecture decision and security review.

Current activity or evidence from the project

Recent repository work has focused on credentialed provider-coverage probing, data-lineage evidence, delivery dry-run validation, local reliability contracts, and project operating memory. The test suite covers the deterministic research, risk, paper-ledger, broker-boundary, database, agent-evidence, observability, reliability, normalization, and coverage-probe surfaces described above.

The strongest current evidence is contract-level and offline. Hosted provider, browser, deployment, production storage, customer, and market-performance evidence remains incomplete or intentionally out of scope.