Skip to content

Latest commit

 

History

History
272 lines (183 loc) · 3.75 KB

File metadata and controls

272 lines (183 loc) · 3.75 KB

trion-dsl

A strict, parseable trading strategy language designed for AI-generated strategies, deterministic backtesting, and zero-hallucination execution pipelines.


Why this exists

Most “AI trading systems” today work like this:

Prompt → AI text → trust the output

That architecture is dangerous.

LLMs hallucinate.
Natural language is ambiguous.
Trading systems require deterministic behavior.

We believe AI should never directly control trading logic through free-form text.

Instead, AI should generate structured strategies that can be:

  • parsed
  • validated
  • rejected
  • tested
  • traced
  • versioned
  • backtested

before anything touches a runtime system.

That is the purpose of trion-dsl.


Core Philosophy

trion-dsl is built around one principle:

AI may suggest.
Systems must verify.

The DSL acts as a safety boundary between:

  • AI reasoning
  • strategy logic
  • backtesting
  • runtime systems
  • risk systems

This makes the architecture dramatically safer than prompt-driven execution.


Design Goals

  • Deterministic parsing
  • Human-readable syntax
  • AI-friendly generation
  • Zero ambiguity
  • Strong validation
  • Observable behavior
  • Backtest-first architecture
  • No runtime hallucinations
  • Safe failure behavior

Example Strategy

STRATEGY momentum_breakout_v1

MARKET BTCUSDT
TIMEFRAME 1h

ENTRY
    EMA(20) > EMA(50)
    RSI(14) > 55
    CLOSE > BB_UPPER(20, 2)

EXIT
    RSI(14) < 45
    EMA(20) < EMA(50)

RISK
    STOP_LOSS 2%
    TAKE_PROFIT 5%
    MAX_POSITION_SIZE 10%

Why DSL instead of prompts?

Prompts are not contracts

Natural language:

Buy when momentum looks strong.

is impossible to validate safely.

A DSL is explicit:

EMA(20) > EMA(50)
RSI(14) > 55

Now the system can:

  • parse it
  • verify indicators
  • reject invalid syntax
  • detect missing parameters
  • backtest deterministically
  • trace decisions
  • version strategies safely

Safety Architecture

The parser is intentionally strict.

Invalid strategies fail immediately.

Examples:

EMA() > RSI

→ rejected

BUY WHEN MARKET FEELS BULLISH

→ rejected

RSI(14) > hello

→ rejected

The goal is not creativity.

The goal is safe machine-readable intent.


AI Integration

The intended architecture is:

AI
→ Strategy Draft
→ DSL Generation
→ Parser Validation
→ Backtest
→ Risk Validation
→ Runtime Approval

AI never bypasses validation layers.


Backtesting Philosophy

Backtests should be:

  • deterministic
  • reproducible
  • observable
  • traceable

The system should never rely on:

  • hidden prompt context
  • unstated assumptions
  • invisible AI reasoning
  • free-form interpretation

Runtime Philosophy

This project does NOT execute real trades.

This project is focused on:

  • strategy structure
  • validation
  • backtesting
  • architecture
  • observability
  • AI safety boundaries

Live trading systems require additional:

  • risk engines
  • execution gateways
  • audit systems
  • hard limits
  • monitoring
  • human oversight

Future Goals

  • AST generation
  • strategy linting
  • strategy optimization
  • static analysis
  • visual strategy graphs
  • deterministic simulation pipelines
  • AI-assisted strategy generation
  • explainability tooling

Example Vision

The long-term vision is not:

“Let AI trade freely.”

The vision is:

“Let AI propose ideas inside systems that are architecturally safe.”

Status

Early architecture project.

Experimental.
Not financial advice.
Not a live trading system.


Related Concepts

  • deterministic systems
  • structured AI outputs
  • event-driven architectures
  • risk-first trading systems
  • contract-first engineering
  • observable AI systems

License

MIT