← STRATA

The Engineering Story

What it takes to build a non-repainting five-timeframe engine inside Pine Script's limits — updated July 2026

STRATA is developed in an AI-assisted workflow, and we are open about that — because it is exactly why we can say this with a straight face: AI made it faster to build. It did not make it easy. This page is for the technically curious; if you just want to trade with the tool, the front page has everything you need.

7 weeks
of development, and counting
~6,200
lines of Pine Script v6
3 + 2
private libraries + published scripts, four-stage publish chain
650+
published versions on TradingView — the main script alone is past build 440
655 M
tokens of AI processing, measured from the session logs still on disk (older sessions have expired)
3.1 M
tokens of generated engineering output across 2,000+ assistant turns and 860+ tool operations

The walls you only find by hitting them

Pine Script is a sandbox with hard, mostly undocumented limits: a 100,256-token budget per compiled script (the reason STRATA is split into three private libraries with a strict publish order), 254 elements per type constructor (our config object sits at 253), 500 ms per loop, and memory ceilings that only show up in Bar Replay or on loaded servers. None of these can be planned around from the documentation — each one was found the hard way, mid-feature, and each one forced a redesign. The library split itself exists only because of these budgets: how Pine inlines same-library calls but not cross-library calls is behavior we had to reverse-engineer empirically before the architecture could work.

There is no local compiler

There is no way to build or test Pine offline. TradingView is the only compiler and the only runtime, so every change ships as a real publish: publish → load the chart → read the error code or the pixels. The main script has been through more than 400 published builds, the libraries through 200+ more — that number is not vanity, it is the shape of the only development loop the platform allows. Around it we built our own structural verification tooling (bracket balance, type-constructor audits, token-budget estimation), because catching a mistake before publishing saves a full cycle.

The hard part is invisible

Anyone can draw boxes on a chart. The work is in what you cannot see: detection that never repaints across five timeframes (confirmed-close idioms, lookahead alignment, realtime traps inside security contexts), mitigation and freshness that stay consistent between an M1 and an M15 chart, and a load-time engine that reconstructs ten weeks of multi-timeframe history — zones, sessions, freshness stars, breaker states — chronologically, in one pass, inside those same runtime budgets. Naive multi-timeframe scripts repaint, lag, or silently drop levels. Silent is the dangerous part.

Why AI alone does not get you there

The model writes Pine quickly. What it cannot do alone: know that a session high is three points too low, that a freshness star should have dropped an hour ago, that a rejection-block anchor sits one candle off — the regressions that matter are visible only to someone who watches these levels trade every day. Every release is verified on live NQ charts, usually on M15/M1 split screens, before it ships; a meaningful share of the 650+ builds exist precisely because a human caught something on a chart that no test could have flagged. Add the ICT judgment calls (when exactly does a breaker form, what invalidates a rejection block) and the platform scars above — that combination, not the code volume, is the product.

Numbers on this page are measured, not estimated: build counts from TradingView's own version counters, code size from the repository, token totals summed from the per-request usage records in our development session logs. Where a number is a lower bound (expired logs), we say so.

← Back to STRATA