The portable log
Every seat keeps a local encrypted, hash-chained event log (tally.db). It is the agent’s history: what happened, in order, sealed at rest under keys derived from your seed, with each event cryptographically linked to its parent. This page explains what goes into the log, what comes out of it, and how you check it.
Capture: sessions go in
Section titled “Capture: sessions go in”The log is harness-agnostic by construction. When a launch verb’s harness exits, Tally captures the session the harness wrote back into the encrypted log as the agent’s next portable context. The capture happens at Tally’s layer, in Tally’s canonical format, not by copying the harness’s native files.
This one design choice is why everything downstream works the same everywhere. Sync does not need to understand Claude Code’s store, pi’s store, or codex’s store; it moves entries of one log format. A session run under any supported harness lands in the same log, chains onto the same history, and syncs through the same pipe. See What syncs, and what the cloud can see.
The portable context: sessions come out
Section titled “The portable context: sessions come out”On top of the raw events sits the portable context: a canonical export of a coding session holding the task, the acceptance criteria, the plan, and a files pointer. It is the unit of continuation. tally session export extracts a harness session into one; tally session materialize turns a stored one back into any supported harness’s native session store so that harness resumes it.
That pair is what tally continue composes: resolve the seat, load the newest context, materialize it into the chosen harness, launch. The context is deliberately a distilled working state, not a byte-copy of a transcript, which is what lets it cross harness boundaries at all.
tally session show prints the digest (or raw JSON) of any stored context, and tally session verify checks the repo against the context’s acceptance criteria, independent of what the harness claimed about its own work.
Branching: strictly, a tree
Section titled “Branching: strictly, a tree”Strictly, the log is a hash tree, not only a chain. Each event seals its parent’s hash. Continue the same stored context twice (say, once under each of two models) and the two sessions become sibling branches from the same parent, each verifying independently. Tamper with any event and its whole subtree fails verification.
Nothing is overwritten to make this work; branches are what an append-only, parent-linked log gives you when two continuations share an ancestor.
Verifying it yourself
Section titled “Verifying it yourself”Two commands answer “is my history intact” from the machine itself:
# walk the entire hash chain; exit 0 if intact, 1 on tamper or gaptally log verify
# the event count, and whether the chain verifiestally statustally log verify is the strict check with a usable exit code; tally status is the one-glance version. Neither asks a server anything, because the log and the proof of its integrity are both local.
What the log is for, in one line
Section titled “What the log is for, in one line”Capture turns any harness’s session into the agent’s history; the portable context turns that history back into any harness’s next session; the hash tree proves the history you resume is the history you left.
Where next
Section titled “Where next”- What syncs, and what the cloud can see : how the log moves between your machines as ciphertext
- Continue, start, and run : the verbs that capture into and materialize out of the log
- tally session : export, materialize, show, and verify, in full