What we’ll write here

An empty blog is honest. Here’s what we plan to publish (engineering deep dives on Pine semantics, transpiler design, and parity-grade backtests) and why we’d rather wait to write it well than rush it.

The figures in this post were measured on May 7, 2026 and are kept as they were. For current results, see how we measure parity.

When we wrote this, the blog was empty on purpose.

In May 2026 the PineForge team was heads-down on the engine: 162 strategies in the parity sweep, 158 hitting strict trade-for-trade, and the codegen shipping as a free hosted API at the time. The marketing site went up first. The writing came next.

What's coming

A handful of engineering posts are queued. We'd rather publish each one with real artefacts (reproducible CSVs, side-by-side traces, code that runs) than ship vibes. Here's the rough roadmap:

The transpiler architecture. How Pine v6's lexer / parser / analyzer feed the C++ codegen, why we chose AOT compilation over an interpreter, and where the transpiler ends and the Apache-2.0 runtime begins.
Parity engineering as a discipline. What it actually takes to hit trade-for-trade agreement with TradingView. The infrastructure (CI sweep, comparison harness), the corpus design, and the methodology we use when two engines disagree by exactly one bar.
Strategies as compiled binaries. The marketplace thesis (planned, no date): why a .so with seller-defined license bounds is a better distribution model than a JSON-encoded signal feed, and how the runtime would handle license checks without phoning home on every backtest.
Optuna + walk-forward, integrated. Planned, no date. Why the optimizer would take a Python lambda objective rather than a UI-built fitness slider, and how out-of-sample validation would be baked into every optimization run.

In the meantime

If you'd like to skip the wait and just use the engine:

We'll add to this list as posts ship. No newsletter spam. When something is worth your attention, we'll send it once.