Documentation / Foundations

Know what the engine means before trusting what it says.

A practical introduction to the Tactfolio strategy model, builder workflow, and research contract.

What Tactfolio is

Tactfolio is a visual research environment for tactical asset allocation. A strategy is an inspectable tree that transforms market observations into portfolio weights. The same saved definition is used for research and, when enabled, portfolio operation.

The core promise

You should be able to answer what the strategy held, why it held it, which information it used, and which exact revision produced the result.

Tactfolio is not a stock-tip feed, an optimizer that hides its objective, or a guarantee that historical performance will continue.

The strategy model

Every strategy begins with an allocation tree. Nodes describe either what can be held, how capital is divided, or which path is active.

AssetA tradable symbol that can receive portfolio weight.
WeightA rule for distributing capital across child nodes.
RouteA conditional choice between different allocation branches.
RankA comparison that selects or weights candidates by a metric.
IndicatorA causal reading such as moving average, momentum, or volatility.
Strategy referenceA pinned revision of another compatible strategy used as a child.

The root produces a target book: symbol weights plus any residual cash. Nested nodes remain structural and cannot reach upward into ancestors, which keeps evaluation local and explainable.

Using the builder

  1. Open the builder and name the decision you are trying to express.
  2. Add assets or groups, then choose how capital flows between them.
  3. Add routes or ranks only where they represent a rule you can explain.
  4. Set rebalance cadence, benchmark, slippage, and any change threshold.
  5. Run the preview continuously while editing; save when the tree represents a meaningful revision.

Start simple

A small tree with one allocation rule and one defensive route is easier to falsify than a large tree assembled from many indicators. Complexity should earn its place through a clear hypothesis.

Open the builder

The backtesting contract

EOD backtests evaluate strategy targets at the official close and declare one engine-owned execution model. The MCP defaults to next_open; the visual product uses the explicit legacy same_close model unless its request says otherwise. The engine retains pre-window history for indicator initialization, while the requested start remains the output boundary.

Execution timing

Under next_open, a close-generated target waits for the next exact provider-adjusted session open. Existing holdings earn the overnight close-to-open return, configured slippage is applied when the book changes at that open, and the newly filled holdings earn the open-to-close return. Missing exact open data is an integrity error; the engine does not fall back to a carried price or a later close. This daily-open model remains a proxy rather than a simulation of auction liquidity, spreads, impact, or order limits.

Under same_close, the engine evaluates and fills at the same official close. A rule that depends on that session’s final close is non-causal/look-ahead under this legacy model. A next-open response can also end with a target that has not yet reached a future session: lastBook remains the allocation actually filled, and pendingTargetBook reports the queued target separately.

Coverage before convenience

Public research begins only when every required strategy input has eligible data. Missing prices are integrity errors; they are not treated as zero return or silently replaced with cash.

Metrics

Results include total return, CAGR when the period is long enough, volatility, maximum drawdown, Sharpe, Calmar, and annualized one-way turnover. Metrics are summaries, not objectives or predictions.

Historical results are evidence, not promises.

Backtests can reveal behavior under the modeled assumptions. They cannot reproduce unavailable information, eliminate selection bias, or predict future liquidity and execution.

Saving and revisions

Saving creates an immutable revision and moves the strategy’s draft pointer. Backtests for saved strategies request an exact revision rather than posting a mutable copy of the tree. A later edit therefore cannot alter an earlier saved input.

The workspace is the library around the builder. It shows each current strategy revision, its persisted research snapshot, and any connection status. A revision change invalidates the old workspace snapshot and makes the new revision eligible for a fresh run.

From research to operation

Broker connections and automation are extensions of a saved strategy—not a second strategy editor. An active deployment pins an immutable revision and graph hash. Later edits remain drafts until explicitly deployed.

Paper operation is a simulator. Live operation remains subject to stronger reconciliation and safety requirements, and the product must fail closed when required data or state cannot be verified.

Build with Codex through MCP

The Tactfolio MCP server gives Codex typed access to the canonical builder and authoritative research API. Agent-authored strategies use the same document factories, mutations, validation, market data, and backtest engine as the visual product.

There is no second strategy language.

The MCP server is an access layer. It reads the live builder contract, carries explicit documents between edits, and validates before research or persistence.

Connect Tactfolio to Codex