# Surani Algo – Project Resume Summary ## Current Status ### Research - ✅ Phase 1 – Complete - ✅ Phase 2 – Complete - ✅ Phase 3 – Complete - ⏳ Phase 4 – In Progress ### Infrastructure - ✅ Spec 10 Risk Engine Interface - ✅ Companion Capital-Source Amendment - ✅ Risk Rule Taxonomy - ✅ Governance Clarification & Infrastructure Amendment - ✅ Final Governance Certification ## Risk Rules ### Rule 1 – Max Open Positions - ✅ Full 8-phase lifecycle complete - ✅ Behavioural Validation complete - ✅ Fully certified ### Rule 2 – Max Positions Per Symbol - ✅ Governance Verification - ✅ Specification Revision - ✅ Independent Specification Review - ✅ Specification Ratification - ✅ Current Lifecycle Stage Certification - ✅ Implementation Revision 0 - ⏳ Independent Implementation Review - ⏳ Implementation Ratification - ⏳ Behavioural Validation Review ### Rules 3–7 - ⏳ Not started --- # Immediate Next Task ## V2 Architecture Migration **Objective** Replace the legacy Generate Signal System with the v2 architecture. The legacy implementation will be retired. The v2 architecture becomes the production system. This phase produces the migration architecture and implementation plan before code changes begin. --- # Target Production Architecture ```text Market Data │ ▼ Signal Generator │ ▼ Filter Engine │ ▼ Risk Engine │ ▼ Order Executor │ ▼ Position Manager │ ▼ Broker ``` --- # Risk Engine Responsibilities The Risk Engine is responsible only for pre-entry decisions. It answers: > "May I open this position?" Examples: - Max Open Positions - Max Positions Per Symbol - Max Positions Per Direction - Max Deployed Capital % - Session Loss % - Intraday Drawdown % - Consecutive Loss Stop --- # Position Manager Responsibilities The Position Manager manages open trades only. It answers: > "How should I manage or exit this existing position?" Responsibilities: - Open position monitoring - Trailing Stop Loss - Break-even movement - Target management - Partial exits - Time-based exits - Sudden spike exits - Volatility exits - Gap handling - Manual intervention - Position health monitoring - Exit decision generation - Position lifecycle management --- # Planned Execution Order 1. Complete V2 Architecture Migration. 2. Replace the legacy Generate Signal System with the v2 architecture. 3. Complete Rule 2: - Independent Implementation Review - Implementation Ratification - Behavioural Validation Review 4. Complete Rules 3–7. 5. Begin governance for the Position Manager subsystem. 6. Implement, review, ratify and validate the Position Manager. --- # Long-Term Architecture Final production components: - Signal Generator - Filter Engine - Risk Engine - Order Executor - Position Manager - Broker Integration Each subsystem follows: 1. Research 2. Specification 3. Independent Specification Review 4. Specification Ratification 5. Implementation 6. Independent Implementation Review 7. Implementation Ratification 8. Behavioural Validation Review --- # Resume Point Resume from: 1. V2 Architecture Migration 2. Migration implementation 3. Rule 2 Independent Implementation Review 4. Rule 2 Implementation Ratification 5. Rule 2 Behavioural Validation Review 6. Rules 3–7 7. Position Manager governance and implementation Phase 0 ──────── ✅ Governance Framework ✅ Rule 1 Complete ✅ Rule 2 Implementation Rev 0 Phase 1 ──────── V2 Architecture Migration Replace the legacy Generate Signal System. Retire the monolithic pipeline. Make v2 the only production analysis engine. Create the new architecture. ──────────────────────────────── Market Data Gateway ↓ V2 Signal Engine ↓ Filter Engine ↓ Risk Engine ↓ Trade Plan ↓ Paper Executor ↓ Position Manager ↓ Paper Trade Lifecycle ──────────────────────────────── Phase 2 ──────── Complete Rule 2 • Independent Implementation Review • Implementation Ratification • Behavioural Validation Review Phase 3 ──────── Position Manager Framework Create • Position Manager Interface • Position Registry • Position State Machine • Position Event Model No policies yet. Phase 4 ──────── Risk Rules Rule 3 Rule 4 Rule 5 Rule 6 Rule 7 Complete all eight lifecycle phases for each. Phase 5 ──────── Position Policies Implement • Hard Stop Loss • Trailing Stop • Break Even • Target Exit • Partial Exit • Spike Exit • Volatility Exit • Session Close • Manual Exit Phase 6 ──────── Frontend Migration Run Analysis ↓ V2 Signal Engine ↓ Trade Plan ↓ Paper Trade ↓ Position Manager Phase 7 ──────── Legacy Cleanup Remove analysis/ strategy/ scalper/ legacy filters legacy risk manager legacy signal generator Phase 8 ──────── Final Production Architecture Market Data Gateway ↓ Signal Engine ↓ Filter Engine ↓ Risk Engine ↓ Paper Executor ↓ Position Manager ↓ Reporting ↓ Analytics Structure: After Position Policy 1 completes Phase 8, the remaining governance scope for the Position Policy framework is: --- # Remaining Position Policy Scope ## Position Policy 2 — Break Even Introduce automatic movement of the protective stop to the entry price once the configured trigger condition has been satisfied. Scope includes: * Governance verification * Behavioural specification * Ratification * Implementation * Validation * Break-even trigger definition * One-time stop promotion * Interaction with Hard Stop Loss * Observation schema * Behavioural invariants --- ## Position Policy 3 — Trailing Stop Implement dynamic stop movement as price advances in favour of the position. Scope includes: * Trailing algorithm * Long/short symmetry * Trail update rules * Non-regression rules * Stop monotonicity * Observation metadata * Integration with Hard Stop Loss --- ## Position Policy 4 — Target Exit Exit a position once the configured profit target has been reached. Scope includes: * Target-price computation * Inclusive trigger semantics * Profit-target observation fields * Interaction with other exit policies --- ## Position Policy 5 — Partial Exit Support staged position reduction while allowing the remaining quantity to continue under policy management. Scope includes: * Partial quantity calculation * Remaining-position handling * Observation updates * Policy interaction rules --- ## Position Policy 6 — Session Close Exit Close open positions according to session-end rules. Scope includes: * Session timing * Forced close conditions * Market close behaviour * Observation recording --- ## Position Policy 7 — Manual Exit Allow externally requested exits to flow through the governed policy pipeline. Scope includes: * Manual exit requests * Policy precedence * Audit recording * Deterministic behaviour --- ## Position Policy 8 — Spike Exit Protect against abnormal adverse price movements. Scope includes: * Spike detection * Threshold evaluation * Immediate exit conditions * Observation payload * False-positive handling --- ## Position Policy 9 — Volatility Exit Exit positions during abnormal market volatility according to ratified rules. Scope includes: * Volatility measurement * Threshold comparison * Policy decisions * Observation metadata * Interaction with existing policies --- # Position Policy Framework Completion When Position Policies 1–9 have completed their individual eight-phase governance lifecycles, the Position Policy subsystem will provide a complete, governed exit framework comprising: * Hard Stop Loss * Break Even * Trailing Stop * Target Exit * Partial Exit * Session Close Exit * Manual Exit * Spike Exit * Volatility Exit Each policy remains: * Independently specified * Independently reviewed * Independently ratified * Independently implemented * Independently validated * Versioned independently * Extendable only through governance-visible amendments This completes the governed Position Policy layer defined within the V2 architecture, after which development can proceed to the next major roadmap areas (additional Risk Rules, strategy governance, replay/backtesting, observability, and scheduler/live runtime integration). Phase 1 — Governance Verification Phase 2 — Specification Revision 0 Phase 3 — Independent Specification Review Phase 4 — Specification Ratification Phase 5 — Implementation Revision 0 Phase 6 — Independent Implementation Review Phase 7 — Implementation Ratification Phase 8 — Behavioural Validation Review / Final Certification **Failure is never quiet.** A failed step produces a log block naming the exit What I'd build next (outside the product) I'd organize a docs/ hierarchy like this: docs/ ├── README.md ← Start here │ ├── developers/ │ ├── QUICK_REFERENCE.md │ ├── COMMAND_REFERENCE.md │ ├── DEBUGGING.md │ ├── TESTING.md │ ├── DEPLOYMENT.md │ ├── CI_GATES.md │ ├── MIGRATIONS.md │ └── ARCHITECTURE.md │ ├── research/ │ ├── GOVERNANCE.md │ ├── CAMPAIGNS.md │ ├── DATASET_PROGRAMME.md │ ├── STRATEGY_REGISTRY.md │ └── ROADMAP.md │ ├── operations/ │ ├── PLATFORM_BROKER.md │ ├── SCHEDULER.md │ ├── RECOVERY.md │ └── MAINTENANCE.md │ └── users/ ├── USER_GUIDE.md └── ADMIN_GUIDE.md Then, have one generated index: Developer Portal Development Quick Reference Command Reference Testing Operations Scheduler Broker Research Governance Campaigns Architecture 7 Aug 2026 I like this direction. At this point, I would deliberately narrow the project's scope. Project Focus (from now on) ✅ Phase 1 — Platform (Complete) Freeze unless there is a bug. Includes: Backend architecture Frontend architecture Market Intelligence AI Scanner Billing Governance Registry Replay infrastructure Contract Funnel CI Testing No new features here unless they fix defects. 🔄 Phase 2 — Strategy Quality (Current Focus) Everything now revolves around improving strategy quality. Examples: Replay Validator Signal quality Entry quality Exit quality False-positive reduction False-negative reduction Strategy explainability Performance across market regimes Confidence calibration Risk tuning 📈 Phase 3 — Trading Intelligence (After strategies mature) Only after strategies are statistically proven. Examples: Strategy comparison Portfolio analytics Live performance dashboards Explainable AI Strategy ranking Institutional reporting Guiding Principle Freeze infrastructure unless a bug is discovered. Every new engineering effort should improve trading quality or research quality—not add platform complexity. 8 Aug 2026 I actually think this is **better** than the earlier roadmap. I would make only one refinement. Instead of saying **"Strategy Quality"**, I'd broaden it slightly to **"Research & Strategy Quality"**, because your Replay Validator, Research Dashboard, and Specification Framework are still active tools—but only insofar as they improve research quality, not infrastructure. Here's the version I would adopt as the project's standing roadmap. --- # Project Focus (from now on) ## ✅ Phase 1 — Platform (Complete) **Status:** Frozen Modify only to: * Fix verified bugs * Fix regressions * Resolve security issues * Correct architectural defects No feature work. ### Includes * Backend architecture * Frontend architecture * Market Intelligence * AI Scanner * Billing * Governance * Registry * Replay infrastructure * Historical Replay * Research Framework * Research Dashboard * Contract Funnel * CI * Testing --- ## 🔄 Phase 2 — Research & Strategy Quality (Current Focus) Every engineering effort must improve either: * Strategy quality * Research quality Examples: ### Research * Replay Matrix execution * Replay Validator * Research Dashboard analysis * Evidence collection * Campaign preparation * Statistical validation ### Strategy * Signal quality * Entry quality * Exit quality * False-positive reduction * False-negative reduction * Confidence calibration * Risk tuning * Performance across market regimes * Explainability Every proposed strategy change must begin with evidence gathered through the research platform. --- ## 📈 Phase 3 — Trading Intelligence (Only after strategies mature) Begin only after strategies have statistically demonstrated an edge through replay and paper trading. Examples: * Strategy comparison * Portfolio analytics * Live performance dashboards * Explainable AI * Strategy ranking * Institutional reporting * Multi-strategy allocation * Capital allocation analytics --- # Standing Engineering Rule Freeze the platform unless a verified defect exists. Every proposed engineering task must answer this question first: > **Does this improve research quality or trading quality?** If the answer is **no**, do not build it. If the answer is **yes**, require supporting evidence before implementation. --- I would also add one final rule because it captures the discipline you've built over the last several months: > **Evidence precedes engineering. Engineering precedes promotion.** That simple sequence reflects your entire workflow: **Replay → Evidence → Research → Strategy Change → Replay Validation → Paper Trading → Production** It's concise, memorable, and reinforces the process you've invested so much effort in establishing. I think you're now here Platform ████████████████████ 100% ✅ Frozen Research Framework ████████████████████ 100% ✅ Frozen Replay Infrastructure ████████████████████ 100% ✅ Frozen Strategy Quality ██░░░░░░░░░░░░░░░░░░ 10% ← Current focus Trading Intelligence ░░░░░░░░░░░░░░░░░░░░ 0% ← Later That's a strong place to be. The platform has transitioned from "building tools" to "producing evidence," which is exactly where a research-driven trading system should be before attempting to improve strategies. Research Specifications ├── ema_crossover_v2_replay_matrix │ ├── ema_behaviour_study │ ├── breakout_behaviour_study │ ├── support_resistance_study │ ├── vwap_behaviour_study │ ├── volume_behaviour_study │ ├── option_chain_behaviour_study │ ├── oi_behaviour_study │ ├── pcr_behaviour_study │ ├── expiry_behaviour_study │ └── future studies... This is the roadmap I'd follow Stage 1 — Research Infrastructure ✅ Complete (freeze) Stage 2 — Behaviour Evidence EMA Behaviour Study Breakout Behaviour Study Support/Resistance Study VWAP Behaviour Study Volume Behaviour Study Option Chain Behaviour Study OI Behaviour Study PCR Behaviour Study Stage 3 — Hypothesis Formation Combine evidence across studies. Identify repeatable, statistically supported relationships. Stage 4 — Campaign D Build or refine a strategy using those validated hypotheses. Validate through replay and governance before considering production. That sequence is methodical and minimizes the risk of overfitting. It also makes every strategy change traceable back to specific evidence rather than intuition. My modificatoins is: This is a new module name is AI auto Scan. On market days, when user comes and press Start AI scan button. System will start AI scan in background cronjob on server with selected Index. At a time only 1 Index can be auto scan in background cronjob. if user try to AI scan cronjob for other Index and if there is a AI scan cronjob is running in background for that user, then It must show a alert that AI scan is running in background. You want to Stop and Start new AI Scan for {Index Name}. If user press yes, then AI auto scan cronjob can be stop current index, and start a new AI scan cronjob for the selected Index. Time will alwasy 30 mins when Start AI scan cronjob. When Scan done it should auto populate the signals genearted by AI auto scan cronjob. Generated signals by AI auto Scan cronjob should be visible for 5 mins only. if I refresh the page then signals should be visible for remaining time of 5 mins. If those signal has any Confirm trade button then Scan count should be consumed in AI auto scan cronjob results. Now after Signal generated successfuly the background AI scan cronjob should be stop for that user. Make sure, user can leave the website. But scheduler cronjob will always scan in background for that user. AI scan cronjob can only stop if Broker Session disconnect or it should auto stop after market close and also there must be a button on UI to stop the AI scan cronjob. Let say I started AI scan cronjob for Nifty. AI scan cronjob will run in background and show a process until get the results It should scan for 30 Mins and after that AI scan cronjob will stop. During this 30 mins if any signals generated with Confirm trade button then AI scan cronjob will stop and show the results. # AI Auto Scan — Functional Requirements ## 1. Overview **AI Auto Scan** is a background market-scanning module that continuously analyzes a user-selected index using AI and the user's connected broker session. On a market day, the user can select an index and click **Start AI Scan**. The system will start an AI Auto Scan background job on the server. The user **does not need to keep the website open**. Once started, the background scan must continue independently on the server. --- ## 2. AI Auto Scan Duration * Each AI Auto Scan session has a maximum duration of **30 minutes**. * The 30-minute duration starts when the user clicks **Start AI Scan**. * After 30 minutes, the background AI Auto Scan job must automatically stop. * The UI should show the scan as **Running** while the background job is active. * The UI should display the selected index and the remaining scan time. Example: > AI Auto Scan is running for NIFTY > Remaining time: 24:35 --- ## 3. One Active AI Scan Per User A user can have **only one active AI Auto Scan at a time**. For example: * User starts AI Auto Scan for **NIFTY**. * NIFTY scan is running in the background. * User then selects **BANKNIFTY** and presses **Start AI Scan**. The system must detect that an AI Auto Scan is already running for the user and show a confirmation alert: > **AI Auto Scan is already running for NIFTY.** > Do you want to stop the current NIFTY scan and start a new AI Auto Scan for BANKNIFTY? Buttons: * **Cancel** * **Stop & Start New Scan** If the user selects **Stop & Start New Scan**: 1. Stop the existing NIFTY AI Auto Scan job. 2. Mark the NIFTY scan as stopped. 3. Start a new AI Auto Scan job for BANKNIFTY. 4. Start a new 30-minute timer for BANKNIFTY. --- ## 4. Background Processing The AI Auto Scan must run as a **server-side background job/cron process**. The scan must continue even if: * The user closes the browser. * The user navigates to another page. * The user logs out of the website, where applicable. * The user's browser is refreshed. The browser UI should only retrieve the current scan status and generated results from the server. The actual scanning, AI analysis, signal generation, timeout handling, and automatic stopping must happen server-side. --- ## 5. Broker Session Dependency AI Auto Scan requires an active broker session. The background AI Auto Scan must automatically stop if the user's broker session becomes disconnected or invalid. Example: > User starts AI Auto Scan for NIFTY → Broker session expires/disconnects → AI Auto Scan automatically stops. The system should store the reason for stopping, such as: * `completed` * `signal_generated` * `timeout` * `broker_disconnected` * `user_stopped` * `replaced_by_new_scan` * `market_closed` * `error` --- ## 6. Market Hours AI Auto Scan should only operate during valid market hours. The system must automatically stop the background scan when the relevant market closes. The user should not be able to start a new AI Auto Scan outside the configured market hours. The market-day and market-hour validation should be performed server-side rather than relying only on the frontend clock. --- ## 7. Manual Stop The UI must provide a **Stop AI Scan** button while an AI Auto Scan is running. When the user presses **Stop AI Scan**: 1. Ask for confirmation. 2. Stop the background AI Auto Scan job. 3. Update the scan status on the server. 4. Stop displaying the scan as active in the UI. Example confirmation: > **Stop AI Auto Scan?** > Your current NIFTY AI Auto Scan will be stopped. Buttons: * **Cancel** * **Stop Scan** --- ## 8. Signal Generation During the 30-minute scan period, the AI continuously analyzes the selected index. If the AI generates a valid trading signal that contains a **Confirm Trade** action, the system must: 1. Save the generated signal on the server. 2. Mark the AI Auto Scan as having generated a successful result. 3. Stop the background AI Auto Scan immediately. 4. Make the generated signal available to the user. 5. Display the signal automatically in the UI. The scan **must not continue for the remaining 30 minutes after a valid signal has been generated**. Example: > AI Auto Scan started at 10:00 AM. > Valid signal generated at 10:07 AM. > AI Auto Scan stops at 10:07 AM. > The signal remains visible for 5 minutes. --- ## 9. Signal Visibility — 5 Minutes Signals generated by AI Auto Scan must be visible for **5 minutes only**. The 5-minute visibility period must be controlled by the server timestamp, not the browser. For example: * Signal generated: **10:07:20** * Signal expires: **10:12:20** If the user remains on the page, the signal should remain visible until its expiry time. If the user refreshes the page, the system must calculate the remaining visibility time from the server-side expiry timestamp. Example: > Signal generated 3 minutes ago → User refreshes → Signal remains visible for approximately 2 more minutes. Once the 5-minute period expires, the signal must no longer be displayed as an active AI Auto Scan result. --- ## 10. Signal Persistence and Expiry The generated signal should be stored with timestamps such as: * `generated_at` * `expires_at` The frontend should never simply assume that a signal is valid for five minutes from page load. The server must determine whether the signal is still active. Example logic: ```text generated_at = 10:07:20 expires_at = 10:12:20 current_time = 10:09:30 Remaining visibility = 2 minutes 50 seconds ``` After `expires_at`, the signal should be treated as expired. --- ## 11. Scan Count Consumption If an AI Auto Scan generates a signal containing a **Confirm Trade** button, the user's applicable scan count must be consumed. The scan count should be consumed based on the **AI Auto Scan result**, not simply because the background scan was started. The consumption should be handled server-side to prevent: * Duplicate consumption from page refreshes. * Multiple API requests consuming multiple scans. * Browser manipulation. * Repeated confirmation/result requests consuming additional scans. The system should ensure that a single generated AI Auto Scan result can consume the applicable scan count **only once**. --- ## 12. UI Behavior When no AI Auto Scan is running: > **Start AI Scan** When an AI Auto Scan is running: > **AI Auto Scan Running** > Index: NIFTY > Remaining: 18:42 > **Stop AI Scan** The UI should periodically retrieve the server-side scan status so that it remains synchronized with the background job. If the user leaves the website and comes back later, the page should retrieve the current status from the server. For example: * Scan started for NIFTY. * User closes the browser. * 10 minutes later, user returns. * Server scan is still running. * UI displays approximately 20 minutes remaining. --- ## 13. Replacing an Existing Scan Example: ### Current state ```text User └── AI Auto Scan ├── Index: NIFTY ├── Status: Running └── Remaining: 21 minutes ``` User selects BANKNIFTY and presses **Start AI Scan**. System detects the existing active scan and displays: > **AI Auto Scan is already running for NIFTY.** > Do you want to stop the current scan and start a new scan for BANKNIFTY? If confirmed: ```text Stop NIFTY Scan ↓ Mark NIFTY as stopped/replaced ↓ Start BANKNIFTY Scan ↓ Start new 30-minute timer ``` There must never be two active AI Auto Scan jobs for the same user. --- ## 14. Scan Lifecycle The complete lifecycle should be: ```text User selects Index ↓ User clicks "Start AI Scan" ↓ Validate: - Market is open - Broker session is active - User is eligible to scan - No active scan OR user confirms replacement ↓ Create AI Auto Scan session ↓ Start background server job ↓ Maximum 30-minute scan window ↓ AI continuously analyzes market ↓ ┌───────────────────────────┐ │ │ ↓ ↓ Valid signal generated No signal ↓ ↓ Save signal Continue scanning ↓ ↓ Stop background job Until 30 minutes ↓ ↓ Show signal Stop automatically ↓ Signal visible for 5 minutes ↓ Signal expires ``` --- ## 15. Possible Stop Conditions The AI Auto Scan background job can stop for the following reasons: | Reason | Behavior | | -------------------------------------------------- | ----------------------------------- | | Signal generated | Stop immediately and show result | | 30-minute timeout | Stop automatically | | Broker disconnected | Stop automatically | | Market closed | Stop automatically | | User manually stopped | Stop immediately | | User starts another index and confirms replacement | Stop current scan and start new one | | System/background job error | Stop safely and record error | --- ## 16. Important Server-Side Requirements The implementation must be **server-authoritative**. The frontend must not be responsible for: * Keeping the scan alive. * Maintaining the 30-minute timer. * Determining whether a scan is still active. * Determining whether a signal has expired. * Preventing duplicate scans. * Consuming scan counts. * Stopping the background process. The backend should maintain the authoritative state of every AI Auto Scan session. A scan session should have a unique identifier and maintain its lifecycle/status on the server. At minimum, the system should be able to determine: ```text User Index Scan Status Started At Expires At Stopped At Stop Reason Generated Signal Signal Expiry ``` --- ## 17. Key Business Rules 1. **One user = maximum one active AI Auto Scan.** 2. **One AI Auto Scan = maximum 30 minutes.** 3. The scan continues even if the user leaves the website. 4. Broker disconnection automatically stops the scan. 5. Market close automatically stops the scan. 6. User can manually stop the scan. 7. Starting another index requires stopping the existing scan first. 8. A valid signal with **Confirm Trade** immediately stops the scan. 9. AI Auto Scan signals are visible for exactly **5 minutes from server-side generation time**. 10. Refreshing the page does not reset the 5-minute signal timer. 11. Scan count is consumed only for applicable generated results and must happen exactly once. 12. All scan state, timers, expiry, and lifecycle decisions must be controlled by the server. 13. After a successful signal is generated, the background AI Auto Scan must stop immediately. 14. The UI must always reflect the actual server-side scan state. 10 Aug 2026: My proposed next phase I would call it: Phase 2B — Live Signal Quality Engine Step 1 Freeze ema_crossover.v2. Step 2 Audit/resolve the live data inputs required for: EMA volume confirmation momentum volatility market structure option selection Step 3 Build a deterministic Signal Quality Engine. Step 4 Implement: SIGNAL / NO_SIGNAL as the primary output. Step 5 Run it in shadow mode against the live market. Step 6 Record every decision: timestamp market state EMA state features score confidence signal/no-signal reason subsequent outcome Step 7 Evaluate the live shadow results. Step 8 Only then connect paper trading. Step 9 Then controlled live deployment. Step 10 Build React Native against the stabilized API. # Surani Algo — Phase Roadmap ## Guiding Principle Freeze completed infrastructure unless a defect is discovered. From this point forward, engineering effort must primarily improve: - signal quality - market understanding - risk control - live reliability - evidence quality Do not continue indefinite historical experimentation. The objective is to move from: Research → Signal Quality → Shadow Trading → Paper Trading → Controlled Live while keeping production trading disabled until the required evidence and operational controls are satisfied. --- # PHASE 1 — PLATFORM ## Status: COMPLETE / FROZEN The platform foundation is complete. Includes: - Backend architecture - Frontend architecture - Market Intelligence - AI Scanner infrastructure - Billing - Governance - Strategy Registry - Replay infrastructure - Research Specifications - Market Behaviour Research - Contract Funnel - CI - Testing - Research Dashboard - Research Matrix - Evidence / Provenance - Research Export - Research Reset ### Rule No new platform features. Only fix defects, security issues, reliability problems, or architectural violations. --- # PHASE 2 — STRATEGY QUALITY ## Status: CURRENT The objective is no longer to endlessly test whether EMA works. The objective is to determine whether the system can identify a GOOD CURRENT-MARKET SETUP and correctly reject poor setups. --- ## PHASE 2A — Historical Research Foundation ### Status: COMPLETE / FREEZE Completed work: - EMA crossover behaviour study - 5-day research - 30-day research - 60-day research - Market Behaviour Library - Condition discovery - Validation / holdout framework - Historical Dataset Audit Important conclusion: Raw EMA crossover did NOT produce a robust condition. Therefore: - Do not modify ema_crossover.v2 - Do not create ema_crossover.v3 - Do not keep running 90/120/180-day EMA experiments against the same deficient observation schema - Do not promote the raw EMA crossover as a proven strategy The research framework did its job. --- # PHASE 2B — Research Instrumentation ## NEXT Objective: Capture market context that already exists in the historical candle corpus but was previously missing from the behaviour observation. Capture where valid and entry-time safe: ### EMA Context - EMA9 - EMA20 - EMA spread - EMA9 slope - EMA20 slope - EMA spread movement ### Candle Context - Open - High - Low - Close - Candle body - Candle range - Upper wick - Lower wick ### Previous-Bar Context - Previous candle direction - Previous 3-candle context - Previous 5-candle context ### Volatility / Structure - ATR - ATR slope - Choppiness - Recent high - Recent low - Range position - Range compression where an approved definition exists ### Time Context - Session date - Event timestamp - Minutes from market open - Correct research-safe time bucket ### Do NOT invent - Support definitions - Resistance definitions - Breakout definitions - Synthetic volume - Synthetic VWAP - Synthetic OI - Synthetic PCR - Synthetic IV - Synthetic Greeks --- # PHASE 2C — Re-observe Existing Historical Corpus ## AFTER INSTRUMENTATION Do not immediately run 180 days. First re-observe the existing historical corpus using the richer observation model. Purpose: Determine whether the additional market context actually provides useful separation between: - successful movement - failed movement - fake breakout behaviour - continuation behaviour - reversal behaviour - sideways behaviour without changing the EMA strategy itself. Every observation must remain: - observational - L1 - production_validated = false - provenance-traceable - deterministic --- # PHASE 2D — Statistical Capacity Review Only after richer observations exist. Determine: - event population - classified population - effect size - minimum detectable effect - independence - session stability - regime coverage - discovery / validation / holdout capacity Do NOT choose 90/120/180 days arbitrarily. Historical expansion should be driven by the statistical question. Possible outcomes: 1. Existing corpus sufficient 2. More historical coverage required 3. Data acquisition required 4. Research hypothesis should be rejected --- # PHASE 2E — LIVE MARKET DATA VALIDATION This is the bridge from historical research to the actual product. Audit the LIVE market data available when the user presses: Run AI Analyse Required live inputs should include only fields that are genuinely available and reliable. At minimum investigate: - NIFTY live price - 1-minute candles - EMA9 - EMA20 - EMA spread - EMA crossover - volume confirmation - ATR / volatility - candle structure - market/session context - option-chain availability - option liquidity - expiry - strike selection CRITICAL: Historical NIFTY index volume is unavailable from the current approved historical source. Do not assume that live volume has the same limitation. Verify the actual live broker/API response before implementing: EMA crossover + volume confirmation. If volume belongs to a different instrument than the underlying index, document exactly what it represents before using it as confirmation. --- # PHASE 2F — LIVE SIGNAL QUALITY ENGINE ## CORE PRODUCT MILESTONE Build the actual engine behind: Index Scanner ↓ Choose AI Strategy ↓ 9 EMA ↓ 1 Minute ↓ 1:1 ↓ Run AI Analyse ↓ Current Market Analysis ↓ SIGNAL / NO SIGNAL The engine must NOT be: "EMA crossed → trade." Instead: Market ↓ EMA Event Detector ↓ Market Context ↓ Confirmation ↓ Signal Quality Score ↓ Risk Gate ↓ SIGNAL or NO SIGNAL --- ## Signal Quality Model Potential inputs: - EMA crossover direction - EMA separation - EMA slope - candle structure - momentum - ATR / volatility - market structure - breakout context - volume confirmation - time-of-day - option liquidity - risk conditions Only use features that are actually available and properly defined. --- ## Signal Output The engine must support two primary outcomes. ### HIGH-QUALITY SIGNAL Example: NIFTY BUY CE Strategy: EMA Crossover V2 Timeframe: 1m Risk/Reward: 1:1 AI Score: 86/100 Confidence: HIGH Reasons: - EMA crossover confirmed - Momentum aligned - Volume confirmed - Volatility acceptable - Market structure aligned - Risk conditions acceptable --- ### NO SIGNAL Example: NO SIGNAL Reason: EMA crossover detected, but confirmation quality is insufficient. AI Score: 54/100 Confidence: LOW The system must NOT force a trade. NO SIGNAL is a valid successful outcome. --- # IMPORTANT AI RULE Do NOT allow an LLM to invent a confidence percentage. Do NOT build: Market → LLM → "87% confidence" → Trade Instead: Market Data ↓ Deterministic Feature Extraction ↓ Signal Quality Model ↓ Calibrated Score ↓ Confidence ↓ Risk Gate ↓ SIGNAL / NO SIGNAL ↓ AI Explanation AI may explain the decision. AI must not fabricate the statistical confidence. --- # PHASE 2G — LIVE AI AUTO SCAN ## PRODUCT WORKFLOW Implement the user's requested workflow: User ↓ Index Scanner ↓ Choose AI Strategy ↓ 9 EMA + 1m + 1:1 ↓ Start AI Scan ↓ Server-side background scan ↓ Current market continuously evaluated ↓ SIGNAL or NO SIGNAL --- ## Scan Rules Each AI Auto Scan: - maximum 30 minutes - server-authoritative - survives browser close - survives page navigation - survives refresh - one active scan per user - requires valid broker session - requires valid market hours - stops automatically when market closes - can be manually stopped - can be replaced by another index after confirmation These are explicit product requirements. :contentReference[oaicite:1]{index=1} --- # PHASE 2H — SIGNAL LIFECYCLE When a valid Confirm Trade signal is generated: 1. Store signal. 2. Store generated_at. 3. Store expires_at. 4. Stop AI Auto Scan immediately. 5. Make signal available to frontend. 6. Display signal for exactly 5 minutes. 7. Server controls expiry. 8. Refresh must not restart the timer. 9. Expired signal is no longer active. Example: 10:07:20 ↓ Signal generated 10:07:20 → 10:12:20 ↓ Signal visible 10:12:20 ↓ Signal expires These timestamps must be server-authoritative. :contentReference[oaicite:2]{index=2} --- # PHASE 2I — SIGNAL EVIDENCE Every live signal decision should become evidence. Record: - scan_id - user - strategy - strategy version - index - timeframe - RR - event timestamp - market state - EMA state - feature values - score - confidence - signal/no-signal - reason - generated_at - expires_at - outcome - broker/data provenance Importantly: Record NO SIGNAL decisions too. Otherwise we only study successful-looking events and create survivorship bias. --- # PHASE 2J — LIVE SHADOW MODE ## CRITICAL Before paper trading: Run the exact production signal engine against the live market. But: NO ORDERS. The system observes and records. For every candidate: SIGNAL or NO SIGNAL Then evaluate what happened afterward. This gives us evidence from the exact pipeline that the user will eventually use. This is more valuable now than another generic historical EMA experiment. --- # PHASE 2K — PAPER TRADING Only after shadow-mode evidence is acceptable. Paper trading must use: - same signal engine - same market data - same entry logic - same stop - same target - same option selection - same risk rules No special "paper strategy." Paper trading should simulate the intended production behaviour. Track: - signal accuracy - false positives - false negatives - slippage - spread - target hit - stop hit - time to target - time to stop - consecutive losses - daily drawdown - signal frequency - market-regime performance --- # PHASE 2L — CONTROLLED LIVE VALIDATION Only after paper trading. Start with: - limited capital - limited number of trades - strict daily loss limit - strict position sizing - kill switch - broker disconnect handling - market-close handling - duplicate-order protection - order-state reconciliation - complete audit trail Do not start unrestricted automated trading. --- # PHASE 2 EXIT CRITERIA Phase 2 is complete only when: 1. Signal engine works on live market data. 2. Signal/no-signal behaviour is deterministic. 3. No-signal behaviour is accepted as normal. 4. Signal quality score is defined and reproducible. 5. Confidence is calibrated or explicitly bounded. 6. Live shadow evidence exists. 7. False-positive behaviour is understood. 8. False-negative behaviour is understood. 9. Paper trading has been completed. 10. Risk controls are proven. 11. Broker failure handling is proven. 12. Duplicate execution is prevented. 13. Market-close handling is proven. 14. Governance allows the next stage. 15. Production execution remains disabled until the acceptance decision. --- # PHASE 3 — TRADING INTELLIGENCE ## AFTER STRATEGY QUALITY IS PROVEN Only after Phase 2 produces statistically and operationally credible signals. Build: - Strategy comparison - Strategy ranking - Portfolio analytics - Live performance dashboard - Explainable AI - Regime-aware strategy selection - Confidence calibration - Strategy performance attribution - Institutional reporting - Cross-strategy risk management The key principle: Do not build Phase 3 analytics around unproven strategies. --- # PHASE 4 — MOBILE APPLICATION ## AFTER SIGNAL API IS STABLE Build React Native after the backend signal contract is stable. The mobile application should consume the same backend APIs as the web application. Do NOT duplicate signal-generation logic in React Native. Architecture: Backend Signal Engine ↓ Signal API / realtime channel ↓ ┌───────────────────────┐ │ │ ▼ ▼ Web Admin / Scanner React Native 1. Verify current live MarketFrame ↓ 2. Verify actual live volume sources ↓ 3. Verify market_trend is truly wired ↓ 4. Implement minimal Signal Quality layer ↓ 5. Run current-market analysis ↓ 6. Record SIGNAL + NO SIGNAL evidence ↓ 7. Shadow mode ↓ 8. Evaluate real live outcomes ↓ 9. Paper trading ↓ 10. Controlled live CURRENT ──────────────────────────── Closed-bar live path ✅ EMA event detection ✅ Signal Quality ✅ OBSERVE mode ✅ Shadow mode ✅ Shadow evidence ✅ Production still locked ✅ NEXT ──────────────────────────── 1. Outcome measurement design 2. Define event identity 3. Define entry/SL/target source 4. Define fixed horizon 5. Define ambiguity rules 6. Implement outcome attachment 7. Backfill/attach outcomes 8. Analyse score → outcome 9. Decide whether score has predictive value 10. Only then consider gate 11 Aug 2026: And given what we're doing now, I think we should add this to the Super Admin UI rather than making you inspect MySQL every day. I would make it something like: Super Admin └── Operations └── Shadow Signals ├── Today's observations ├── SIGNAL ├── NO_SIGNAL ├── REJECTED ├── Quality Score ├── Direction ├── Spot ├── Contract ├── Entry / SL / Target ├── Filter verdict └── Full JSON / Evidence Most importantly, this should be read-only and should read the existing ops_decisions data. No new trading path, no broker action, no paper-position creation. That would be a very useful next UI task because we're now collecting real shadow observations every market day. I also need to export to a JSON file by day. So in the UI, the first option is Choose the date to load Shadow Signal data. Then add a Download JSON button on the UI. 1. Amend A-64 properly ↓ 2. Backfill Aug 3–11 option candles ↓ 3. Verify option coverage through 15:39 ↓ 4. Run CI + frontend build ↓ 5. Do NOT modify EMA / M4 / Signal Quality ↓ 6. Resume Shadow Mode ↓ 7. Attach actual option-level PAPER outcomes ↓ 8. Collect multiple sessions ↓ 9. Evaluate Signal Quality / filters 12 Aug 2026: After 16:00 IST Run these in order: cd backend python -m capture_scheduler status Then: python -m research_platform status Then: launchctl list | grep research-capture And, if the scheduler reports success: python scripts/capture_weekly.py --status What we're looking for The decisive transition is: last session : never run → last session : 2026-08-12T16:00+05:30 OK and: OVERDUE : session has never run should disappear. The daily agent's 78 is not today's session job. Leave it alone for now; it's historical evidence. So at this point, the implementation and deployment are done. We are in the observation/verification phase. 2026-08-12 13:43:13 | WARNING | [security] Redis unavailable (Error 61 connecting to localhost:6379. Connection refused.); using in-memory store. This is fine for dev but NOT for multi-worker production.