How Tessera works

Tessera is a declarative format for market strategies, an open-source engine that backtests them, and a runtime that trades them live — the same document for both. This is the human overview; the machine-readable, scannable version is at /llms.txt, and a draft JSON Schema and a worked sample sit alongside it.

Status: design. No engine has shipped, and the source repository is not open yet — it opens with the v0 licence. What is published is the design itself: decisions, specs and roadmap are being written down as we go; join early access to get involved.

The strategy format

Two layers: a closed algebra over an open vocabulary

A strategy is a document, not code — validated as a whole before anything runs. It is built from a small closed algebra (operators, predicates, combinators — extended only by editing the schema, which is rare) over an open vocabulary of observables (spot, atm, pnl, pin_bar, …). Adding a new strategy primitive is registering an observable — not a schema change, a regeneration and a release.

Everything carries a unit

Every expression node has a unit — Money, Count, Ratio or Bool — and a selector's target must agree with what it selects on. A nonsensical combination (comparing an open-interest count to a money value, say) is rejected at validation with a message naming the offending field — not discovered six hours into a run. That is also what makes the format agent-authorable: a machine that gets a precise rejection can correct itself.

Selectors, references and inter-leg dependencies

A leg picks a contract with a selectoron an axis (Strike/Premium/OI/Delta), a pick (Nearest/Max/Min/AtStep), against a target expression. A target can reference another leg — Strike(short_call) — so a hedge wing is defined relative to the leg it protects, not to the market. Spreads, condors and ratio structures become expressions, not bespoke code.

Triggers and exits

Entry can be conditional on a trigger (a predicate over observables, evaluated at each candidate instant). Exits use the same predicate language over observables like pnl and credit — so a profit target, a stop, and a thesis-invalidation exit are all expressible, and a trigger that doesn't fire is correct behaviour (no_trigger), not an error.

Correctness by construction

A backtest that produces plausible-but-wrong numbers is the worst thing this software can do — and with live execution, that wrong number has money attached. So:

Data: ticks are the primitive

Tessera stores ticks — the finest truth a vendor gives — and derives bars at any resolution as cached aggregations (a 1-minute OHLCV bar is open=first, high/low=max/min, close=last, volume=Σqty, oi=last). From ticks, any resolution is recoverable and a faithful intrabar stop is possible; from bars, nothing finer is. One Store interface serves it, backed by local files (default, serverless) or Postgres (shared).

Bring your own source

A Provider declares which capabilities it implements — an instrument master, a historical source, a live source, an execution venue. A bulk vendor file is a historical source that reads files; a broker API like Zerodha, Upstox, IBKR or Alpaca is data and execution over one credential. You bring the key; conversion runs on your machine; the data never reaches us.

Live execution

The document you backtested drives real orders — but through a separate runtime, never the backtester's assumptions. A shared evaluation core emits intents; the live runtime passes each through a risk gate the strategy cannot bypass, places it with an idempotent, restart-safe client order id, reconciles against the broker (which owns the truth), and can be stopped by a kill switch that works without the strategy's cooperation. Paper mode comes first, enforced by the system.

Roadmap, briefly

One thin vertical slice end to end (v0: NSE index options, one source, the CLI, a real strategy reproduced byte-for-byte on two machines), then widen one axis at a time — observables & triggers, API sources, a Postgres backend, an API + web UI, equities, a second venue, then live execution, then an optional cloud topology. See the roadmap.

Going deeper

This page is the overview. The architecture reference is the working document behind it — the layered design, the tick-primary storage model and why it takes two formats, the error taxonomy, the full decision log, and what is built so far. It is updated as decisions land.