Tarski/ docs
Join the waitlist

Quickstart

Scaffold a Tarski app, watch verification prove the contract holds, and take the same app to the cloud — in about five minutes.

Every scaffolded Tarski app verifies green from its first minute — the scaffold is a working curriculum, not an empty folder. This page walks the local loop, then the cloud path.

The local loop

  1. Scaffold an app

    tarski scaffold my-app --pattern minimal
cd my-app

    The minimal pattern is domain-neutral: a commented ontology, a stub mapper, a non-vacuous happy-path fixture, and a manifest. Prefer --pattern default for a fuller curriculum app with a declared query, decision gating, and richer fixtures. Other patterns: sensor (fallible extraction), decision (LLM proposal gating), chat (agent interface), end-user-auth (verified identity and policy-gated access).

  2. Prove the contract

    tarski verify

    verify replays every fixture on a clean database against the deterministic evaluator and layers checks over the replay: golden expected outputs, invariants, provenance, replay determinism, and redaction. It always ends with a human- and machine-readable verdict. Green means the declared contract holds.

  3. Replay a timeline

    tarski replay fixtures/happy-path.jsonl --isolated

    A fixture is an observation timeline (.jsonl) plus an expected world (.expected.json). Replay shows you the derived model those observations produce; --isolated leaves your workspace’s default lineage untouched.

  4. Start the dev loop

    tarski dev

    The dev loop watches your app’s text assets — .ta ontology, Rhai mappers, fixtures — and hot-reloads on change. There is no compile step: apps are directories of text files interpreted by the tarski binary.

  5. Inspect in Studio

    tarski studio

    Studio shows observations, derived facts, intents, effects, and — most importantly — provenance: why each derived fact exists, traced back to the observations that support it. See Studio.

What you just proved

The scaffold’s fixture states a timeline of observations and the exact derived world that must result. tarski verify executed it against the same evaluator that runs production — there is no test-harness translation layer to drift. When you (or your coding agent) change a rule, the fixture either still holds or names exactly what changed.

The cloud path

When you are ready to run hosted, the same app deploys to Tarski Cloud:

tarski cloud login --email you@company.com
tarski cloud whoami
tarski cloud select --project my-project
tarski cloud deploy
tarski cloud observe --kind example.created --payload '{"id":"example-1"}'

Login is a code-only email flow — Tarski emails a sign-in code, which you can supply interactively, via --code, or via --code-command for agent-driven workflows. A denied cloud select exits nonzero and leaves your previous scope untouched, so a chained select && deploy can never deploy to a stale target.

Where next