Architecture.

01The eight-layer stack

Data flows top-to-bottom. Governance flows bottom-to-top. Feedback (forensics, corrections) flows both ways.

02Data stores

03Analyst — cross-asset thesis engine

The Analyst is a macro-level thesis engine. It does not execute trades. Every 30 minutes it ingests the NRU digest buffer, loads prior theses from Redis, collects trading-unit feedback, gets live price snapshots, calls its dedicated REI unit, and writes updated output to Redis for trading units to consume on their next cycle.

Output structure

interface AnalystOutput {
  activeTheses: AnalystThesis[];      // named theses with conviction, direction, invalidation
  recentlyKilled: AnalystThesis[];    // theses invalidated this cycle
  crossPortfolioAlert: {              // portfolio-wide risk alerts
    active: boolean;
    type: string | null;
    message: string | null;
  };
  domainGuidance: {                   // per-asset-class bias
    crypto?: DomainGuidance;
    equity?: DomainGuidance;
    fx?: DomainGuidance;
  };
  forwardLooking: {
    recommendedPosture: 'FULL_DEPLOYMENT' | 'TACTICAL_ONLY' | 'REDUCE' | 'NO_NEW_RISK';
    scenarioProbabilities: { baseCase, bullCase, bearCase, reversalCase };
    alreadyPricedScore: number;       // 0-100: how much is priced in
    marketAheadOfDataScore: number;   // 0-100: how far ahead market moved
  };
  analysis: {
    digestSummary: string;
    thesisChanges: string;
    marketRead: string;
    upcomingCatalysts: string;
    keyRisks: string[];
  };
}

Thesis lifecycle

• Status transitions: ACTIVE → WEAKENING → KILLED
• Conviction tiers: EXTREME · HIGH · MEDIUM · LOW
• Direction per instrument: e.g., { BTC: "BULLISH", GOLD: "BULLISH", USD: "BEARISH" }
• Invalidation conditions: specific conditions that would kill the thesis, stored as a watchlist
• Confirmation conditions: what would strengthen it
• Age tracking: formedAt, lastReinforced, ageHours
• Conviction history: array tracking conviction changes over time

Posture → PM behavior

04Deterministic governance detail

Every component in L6 is pure math, no AI calls, no cycle dependencies. Each runs in OFF, ADVISORY, or ENFORCING mode.

Portfolio Manager

• Posture gate: Analyst recommended posture as hard filter before individual evaluation
• Exposure limits: max gross exposure, max per-sector, max per-strategy-bucket
• Redundancy detection: similar position exists? reduce or reject
• Capital policy: max concurrent positions, min position size, max position size
• Strength governance: weak-strength entries get sizing penalty; strong entries favored
• Decisions: APPROVE · REDUCE (shrink with reason) · REJECT (block with reason)

Entry State Machine

Profit Ladder

Deterministic partial profit-taking, never AI-dependent. Rungs by asset class: at +X% profit → scale out Y% of position. Progressive stop tightening as profit grows. Tracks executed rungs per position to prevent double-execution. Actions: HOLD, TIGHTEN_STOP, SCALE_OUT_PARTIAL, SCALE_OUT_AND_TIGHTEN.

Risk Brake

• Session boundary risk: pre/post US open/close → tighter sizing, stops
• Shock move detection: rapid adverse PnL drop → emergency action
• Profit giveback: gave back >45% of peak profit → tighten or reduce
• Event invalidation: thesis invalidation event → reduce/close per config

Re-entry Controller

JUST_STOPPED → (4h cooldown) → WAITING_RECOVERY →
  (price reclaims + thesis active) → RECOVERY_CONFIRMED →
  REENTRY_ALLOWED_HALF (50% size) → REENTRY_ALLOWED_FULL (full)

Blocks re-entry after: 3 consecutive stops on same symbol, thesis killed, within cooldown.

Price Sentinel

Runs every 60 seconds, independent of trading cycles.

After acting, Sentinel injects sentinelActions[] into the next cycle so the AI knows what happened.

Post-Trade Forensics

Scores every closed trade on decision quality across six labels:

• Thesis failure — idea was wrong
• Expression failure — right idea, wrong instrument
• Entry timing — entered too late or chased
• Stop placement — stopped out before thesis played out
• Profit harvesting — left too much on the table
• Premature exit — closed too early, thesis still valid

Labels feed back to Analyst and trading units for idea-quality-vs-execution-quality separation.

05Scheduler — cycle orchestration

Dynamic intervals respond to: market session, position floor (minimum when positions open), AI-recommended next-check interval, performance state, recent position closes, news and research triggers. Weekend gate suppresses trading cycles Saturday through Sunday evening; ingestion continues.

06Execution layer

Central execution service: TradingService. Receives approved signals from the governance pipeline and executes them.

Execution methods

• IOC (Immediate or Cancel). Default for normal entries. Includes slippage buffer.
• TWAP (Time-Weighted Average Price). Large orders split into N sub-orders over T minutes. Reduces market impact.
• Limit chase. Place limit at current price, adjust every N seconds. Better fill quality than market.

Safety features

• Duplicate close guard — in-flight close promises prevent concurrent close attempts on same position
• Recently opened guard — 60-min duplicate guard prevents re-opening same symbol
• Closed-by-bot tracking — prevents sync from double-recording bot closes as external
• Direction guard — prevents closing LONG then immediately opening same-direction LONG
• Kill switch — tradingPaused flag stops all new execution globally

Exchange integrations

07Research pipeline

Document ingestion pipeline for IB Equity. Runs in six stages from upload to cycle-payload injection.

1. Upload             PDF / DOCX / image uploaded via API
2. Kimi OCR           Moonshot AI extraction · handles scans, charts, tables
3. REI extraction     thesis, catalysts, risks, tickers, themes, conviction, timeHorizon
4. PostgreSQL         store in ib_equity_research table
5. Teaching call      dedicated call to IB Equity REI unit, tracked in Redis 90d
6. Cycle payload      buildResearchContext() injects into every IB Equity cycle

Extraction structure

interface ExtractionResult {
  thesis: string;
  catalysts: string[];
  risks: string[];
  tickers: string[];
  conviction: 'HIGH' | 'MEDIUM' | 'LOW';
  timeHorizon: string;              // e.g., "3-6 months"
  actionableSummary: string;
  themes: string[];                 // AI_INFRASTRUCTURE, DEFENSE, etc.
}

08Data services layer

09Reasoning, data, and governance surface

Reasoning units

Each unit runs on an isolated reasoning channel. Unit-level credentials and internal identifiers are not published.

Data partners

Governance controls

Every governance layer can be independently run in one of three modes, so new rules are paper-tested before they gate real capital:

Position Manager, Risk Brake, Entry State Machine, and Profit Ladder each carry independent mode settings.

10Hanabi-2 — probabilistic forecasting (forthcoming)

What it is

Hanabi-2 is a proprietary prediction model, not part of the REI Core reasoning engine. Where REI Core produces structured analytical reasoning (theses, verdicts, position reviews), Hanabi-2 produces numerical probability distributions over future price paths. The two are complementary: REI Core decides whether a thesis is valid; Hanabi-2 quantifies what the market is likely to do over a specific horizon.

Division of labor between Ecliptica and REI Labs on Hanabi-2: REI handles model architecture, training, and infrastructure. Ecliptica defines product requirements, institutional client specifications, integration surface, and the data contract between Hanabi-2 outputs and STRATA's consumers.

Architecture overview

Why probabilistic outputs

Point forecasts are insufficient for institutional decision-making. A model that says "BTC goes to 52,000 in 4 hours" is not actionable without a confidence measure. An MDN output produces a full distribution: mean, variance, skew, and tail behavior. Downstream consumers can query "what is the probability BTC is below 48,000 in 4 hours" or "what is the 5th-percentile outcome" — the information needed for position sizing, stop placement, and tail-risk hedging.

Integration surface (planned)

When production-integrated into STRATA, Hanabi-2 will plug in at two points:

• Cycle payload enrichment. Trading units receive a hanabiForecast field alongside volatilityContext — per-symbol distributions at each horizon. REI Core's reasoning incorporates the distribution shape into its proposal logic.
• Deterministic governance input. Entry State Machine can use tail probabilities to refuse entries where adverse-move probability exceeds a threshold. Profit Ladder can tune rung placement to realized-volatility forecasts rather than historical ATR alone.

Institutional API (planned)

Hanabi-2 is also intended to be available to institutional clients as a standalone forecast product via the Ecliptica Intelligence API, independent of STRATA deployment. Clients can consume distribution outputs directly into their own risk and sizing systems. Commercial terms to be defined.

For unit-by-unit detail (trading units, review units, intelligence units, primordials per unit, teaching endpoints), continue to units. For the edge framing, see the edge. For LP-grade risk posture, see diligence.