An AI-native trading research assistant that converts natural-language market questions into structured, well-defined research experiments.
Assignment: Option 1 — AI Trading Research Assistant Mini Prototype
- Node.js v18+ (tested on v20 & v24)
- npm or yarn
npm installnpm run devOpen http://localhost:3000 in your browser.
Note on LLM API Keys: The application includes a built-in intelligent NLP heuristic parser, meaning it runs 100% out of the box without any external API keys. If you want to use live LLM APIs, simply add your
GEMINI_API_KEYorOPENAI_API_KEYin.env.local(see.env.example).
Trading research often starts with a simple question such as:
"Does buying NIFTY after a 1% fall work better during high-volatility periods?"
However, natural-language questions are often incomplete or ambiguous. Before such a question can be tested, important parameters such as the instrument, timeframe, entry condition, exit condition, holding period, and relevant filters need to be clearly defined.
The goal of this prototype is to build a small AI-powered web application that can:
Natural Language Question
↓
Understand the Question
↓
Identify Missing Information
↓
Clarify With the User
↓
Structure the Experiment
↓
Present the Final Experiment
The prototype focuses on the research-definition stage rather than building a complete trading platform or production-grade backtesting engine.
The primary objective is to demonstrate how an AI system can transform an ambiguous trading research question into a structured experiment.
For example:
"Does buying NIFTY after a 1% fall work better during high-volatility periods?"
| Parameter | Value |
|---|---|
| Instrument | NIFTY |
| Timeframe | Daily |
| Entry Condition | NIFTY falls ≥ 1% |
| Filter | High volatility |
| Exit Condition | To be specified |
| Holding Period | To be specified |
| Research Question | Does the strategy have a positive edge? |
Instead of making important assumptions automatically, the system identifies missing information and asks the user to clarify it.
The application follows a simple research workflow:
ASK
↓
User enters a research question
CLARIFY
↓
AI identifies missing or ambiguous parameters
DEFINE
↓
Question is converted into a structured experiment
REVIEW
↓
User reviews and confirms the experiment
TEST
↓
Experiment can be passed to a testing/backtesting layer
LEARN
↓
Results can eventually be presented and interpreted
For this mini prototype, the primary implemented flow is:
ASK → CLARIFY → DEFINE
A lightweight testing layer can be added as an extension.
The application follows a modular architecture where the LLM is responsible for understanding natural language, while application logic is responsible for validation and experiment handling.
USER
│
▼
┌─────────────────────┐
│ FRONTEND │
│ │
│ Question Input │
│ Clarification UI │
│ Experiment View │
└──────────┬──────────┘
│
│ API Request
▼
┌─────────────────────┐
│ BACKEND │
│ API Layer │
│ │
│ /api/experiment │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ LLM SERVICE │
│ │
│ Question Parsing │
│ Parameter Extraction│
│ Ambiguity Detection │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ STRUCTURED JSON │
│ │
│ Instrument │
│ Timeframe │
│ Entry │
│ Exit │
│ Holding Period │
│ Filters │
│ Question │
│ Missing Fields │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ VALIDATION │
│ │
│ Schema Validation │
│ Required Fields │
│ Missing Information │
└──────────┬──────────┘
│
┌────────┴────────┐
│ │
Incomplete Complete
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ CLARIFICATION │ │ EXPERIMENT │
│ UI │ │ VIEW │
└────────┬────────┘ └────────┬────────┘
│ │
└──────────┬─────────┘
▼
┌─────────────────────┐
│ EXPERIMENT OBJECT │
│ │
│ Ready for future │
│ backtesting engine │
└─────────────────────┘
The user enters a natural-language research question through the frontend.
Example:
Does buying NIFTY after a 1% fall work better
during high-volatility periods?
The frontend sends the question to the backend API.
POST /api/experiment
The backend acts as the orchestration layer.
It:
- Receives the user's question.
- Sends it to the LLM service.
- Receives structured output.
- Validates the output.
- Determines whether clarification is required.
- Returns the appropriate response to the frontend.
The LLM converts natural language into structured experiment parameters.
Example:
{
"instrument": "NIFTY",
"timeframe": "Daily",
"entryCondition": "NIFTY falls >= 1%",
"exitCondition": null,
"holdingPeriod": null,
"filters": [
"High volatility"
],
"question": "Does buying NIFTY after a 1% fall work better during high-volatility periods?"
}The LLM is used primarily for language understanding and structuring, not for performing financial calculations.
After the LLM produces the structured object, the application checks whether important parameters are missing.
For example:
Entry Condition ✓
Instrument ✓
Timeframe ✓
Filter ✓
Exit Condition ✗
Holding Period ✗
The application then changes the experiment status to:
needs_clarification
The user is asked to provide the missing information.
This prevents the system from silently inventing important trading parameters.
The frontend presents only the information that needs clarification.
Example:
Your experiment is almost ready.
We need two more details:
1. How long should the position be held?
○ 1 day
○ 3 days
○ 5 days
○ 10 days
○ Custom
2. What should trigger the exit?
○ End of holding period
○ Target return
○ Stop loss
The user's answers are merged with the previously extracted experiment.
Once all required information is available, the system generates a final structured experiment.
Example:
{
"instrument": "NIFTY",
"timeframe": "Daily",
"entryCondition": "NIFTY falls >= 1%",
"exitCondition": "Exit at next day's close",
"holdingPeriod": {
"value": 1,
"unit": "day"
},
"filters": [
"High volatility"
],
"question": "Does the strategy have a positive edge?",
"status": "ready"
}The frontend displays this in a clean experiment card.
The experiment object is the central data structure of the application.
interface TradingExperiment {
instrument: string;
timeframe: string;
entryCondition: {
description: string;
threshold?: number;
};
exitCondition: {
description: string;
} | null;
holdingPeriod: {
value: number;
unit: "days" | "weeks";
} | null;
filters: string[];
testPeriod?: {
start: string;
end: string;
};
question: string;
hypothesis?: string;
missingInformation: string[];
assumptions: string[];
status:
| "needs_clarification"
| "ready"
| "tested";
}Using a common experiment object makes the system easier to extend later.
For example:
Structured Experiment
│
├── Current Prototype
│
├── Backtesting Engine
│
├── Historical Data API
│
└── Research Memory
- Next.js
- React
- TypeScript
- Tailwind CSS
- Next.js API Routes
- TypeScript
- LLM API for natural-language understanding and experiment extraction
- Zod / schema-based validation
For the prototype, persistent database storage is not essential.
The architecture can later be extended with:
- Supabase
- PostgreSQL
- Other suitable databases
ai-trading-research-assistant/
│
├── app/
│ ├── page.tsx
│ │
│ ├── api/
│ │ └── experiment/
│ │ └── route.ts
│ │
│ └── experiment/
│ └── page.tsx
│
├── components/
│ ├── QuestionInput.tsx
│ ├── ClarificationPanel.tsx
│ ├── ExperimentCard.tsx
│ ├── ExperimentField.tsx
│ ├── ResultCard.tsx
│ └── LoadingState.tsx
│
├── lib/
│ ├── llm.ts
│ ├── prompts.ts
│ ├── validator.ts
│ └── experiment.ts
│
├── types/
│ └── experiment.ts
│
├── data/
│ └── mockData.ts
│
├── public/
│
├── README.md
├── package.json
└── .env.local
Instead of:
User → LLM → Answer
the architecture uses:
User
↓
LLM
↓
Structured Data
↓
Validation
↓
Application Logic
↓
Experiment
This makes the AI component meaningful rather than simply creating a chatbot wrapper.
The system does not silently invent parameters such as holding period or exit conditions.
Instead:
Missing Information
↓
Ask User
↓
Confirm
↓
Experiment
The structured experiment can eventually be connected to:
Historical Market Data
↓
Backtesting Engine
↓
Statistical Analysis
↓
Research Result
LLM
→ Understand language
Backend
→ Orchestrate workflow
Validator
→ Ensure reliable structure
Frontend
→ Communicate with user
Experiment Engine
→ Perform deterministic calculations
The current prototype can eventually evolve into:
USER
│
▼
AI RESEARCHER
│
▼
EXPERIMENT BUILDER
│
▼
BACKTESTING ENGINE
│
┌─────────┴─────────┐
▼ ▼
MARKET DATA PARAMETERS
│ │
└─────────┬─────────┘
▼
TEST RESULTS
│
▼
STATISTICAL ANALYSIS
│
▼
AI INTERPRETATION
│
▼
RESEARCH MEMORY
│
▼
NEXT EXPERIMENT
This creates the longer-term research loop:
Question
↓
Hypothesis
↓
Experiment
↓
Evidence
↓
Learning
↓
New Question
This prototype intentionally does not attempt to build a production-grade trading platform.
Current limitations include:
- Limited market data
- No production-grade backtesting engine
- No live trading
- No brokerage integration
- Limited experiment types
- Limited statistical analysis
- No comprehensive research memory
These are deliberate scope decisions for the mini prototype.
With more development time, I would add:
- Historical market data APIs
- Multiple instruments
- Multiple timeframes
- Data quality checks
- Proper backtesting
- Transaction costs
- Slippage
- Position sizing
- Benchmark comparison
- Better ambiguity detection
- Experiment refinement
- Automatic hypothesis generation
- Research-history awareness
Store previous experiments:
Experiment 1
↓
Result
↓
Learning
↓
Experiment 2
This would move the system toward the larger vision of an AI-native trading research platform.
AI development tools are used as development partners rather than as a replacement for system design.
- ChatGPT
- [Add Claude / Cursor / GitHub Copilot here if actually used]
- Brainstorming architecture
- Designing the experiment schema
- Generating and refining implementation ideas
- Debugging
- Improving UI/UX
- Reviewing code
- Overall user workflow
- Clarification-first approach
- Separation between LLM and deterministic application logic
- Experiment data structure
- Architecture
- Product decisions
AI-generated suggestions were reviewed and modified wherever necessary to ensure the implementation matched the assignment requirements and remained understandable.
The central design principle of this project is:
The AI should help the user formulate a research experiment, not blindly make decisions on the user's behalf.
Therefore:
Natural Language
↓
AI Understanding
↓
Structured Experiment
↓
Human Confirmation
↓
Experiment
This keeps ambiguity visible and creates a foundation that can later connect to a real backtesting and research system.
This prototype demonstrates how an AI-native trading research assistant can transform an informal market question into a structured research experiment.
The focus is not on building the largest trading system, but on demonstrating:
- Clear product thinking
- Meaningful AI usage
- Ambiguity handling
- Structured experimentation
- Modular architecture
- Extensibility toward future backtesting and research workflows