Architecture

The architecture stack below is interactive. Click a layer to inspect its runtime boundary, owned nodes, responsibilities, state boundary, and security boundary.

Scroll-driven walkthrough

The system changes state as you move through the workflow

This section reacts to scroll and click. Move down the story and the visual panel updates to match the current operating stage.

Scroll reactiveSticky visualClick override

feed pressure

Signals enter as live feeds and market snapshots

Intake pressure rises as fresh sources land in the current snapshot.

feedssnapshotsfreshness

System topology

Click a layer to see where it runs and what it owns

This view compresses the stack into interface, analytics, graph, replay, and storage. Clicking a layer now exposes owned nodes, storage boundaries, and security boundaries.

FrontendSidecarHistorical archive

Browser / desktop shell

Interface layer

The operator surface renders maps, panels, hover states, replay controls, and focus-preserving navigation. It should stay responsive while exposing high-density signals.

Responsibilities

• keep variants coherent
• preserve context across pivots
• keep dense data readable

Owned nodes

Node detail

panel layout

Owns panel composition, variants, and shell mounts.

Main flows

• renders normalized state
• routes focus and click events
• surfaces alerts and replay outputs

State and storage boundary

• short-lived browser state and UI preferences
• desktop shell bridges into sidecar-only actions

Security and ops boundary

• never expose credentials client-side
• use sanitized public screenshots only
• avoid leaking local-only endpoints

Related docs

ArchitectureFeatures

Main subsystems

• operator shell and panel system around event-dashboard.html
• ingestion and normalization services for feeds, macro, market, and event sources
• canonical event layer that resolves raw article rows into reusable signal objects
• interpretation and decision-support services for briefs, proposals, approvals, and diagnostics
• evidence-first report pipeline that separates client memo, audit appendix, exhibits, validation, and source-query/backfill tasks
• Python batch compute lane for clustering, return analytics, and model training
• historical replay and archive services for downstream calibration
• desktop sidecar and local APIs for desktop-aware execution
• storage envelope, schema registry, and retention pipeline across NAS PostgreSQL, snapshots, DuckDB, and local cache

Runtime boundary

The current runtime split is workload-driven:

TypeScript owns

• browser UI and workspace shell
• API handlers and edge/server surfaces
• feed orchestration, scheduling, and ingestion
• desktop orchestration and local sidecar wiring

Python owns

• canonical-event clustering
• abnormal-return analytics
• model training and comparison
• future CPU-bound finance, clustering, and simulation ports

Rust owns

• Tauri runtime and native desktop lifecycle only

This keeps product surfaces in TypeScript while moving heavy batch compute to the toolchain that fits it.

Current data-to-decision flow

1. raw feeds and structured sources are collected and normalized
2. canonical event resolution groups related evidence before scoring
3. interpretation services build theme briefs, proposals, and operator context
4. report services compile evidence bundles, signal cards, analyst synthesis, long-form memo sections, exhibits, and audit appendices
5. Python batch compute writes reusable results back to PostgreSQL
6. replay and historical validation evaluate whether the live logic stays calibrated

The important design change is that raw rows are no longer treated as final signal objects, and heavy compute is no longer forced through handwritten Node loops.

Evidence-first report boundary

Reports are compiled from stored evidence, metrics, market reactions, caveats, and figure specs. The client memo is the readable analyst layer; provenance and raw ledgers stay in the audit appendix.

The report pipeline is:

DB/API/cache data
-> evidence bundle
-> deep research packs
-> signal cards
-> analyst synthesis
-> semantic narrative blueprint
-> long-form client memo
-> validator and quality gates
-> source-query/backfill tasks

Quality is intentionally split. A report can be a strong research-prioritization memo while still not being investment-ready. Direct transcript coverage, controlled market validation, and independently supported causal mechanisms are hard gates for stronger claims.

Reference docs

• Architecture deep dive
• Compute language migration plan
• Desktop runtime
• Historical data sources
• Phase 7 implementation notes
• Intelligence server schema
• Service server plan
• Intelligence report generator
• Report output layer

Public boundary

This site documents architecture decisions and major flows while omitting private operations, secrets, and sensitive deployment details.