ito for Lawyers

You already do version control. You just do it with filenames.

Everyone recognizes this. Nobody defends it. The filename is carrying weight it was never designed to bear — who edited it, when, which direction the changes went, whether this is the version opposing counsel saw. And when something goes wrong, you reconstruct the timeline from file dates and memory.

Programmers solved this problem decades ago with version control. But their tools — git, specifically — were built for code. They require a terminal, think in branches and commits and diffs of plain text, and assume you know what a merge conflict is. No lawyer should have to learn git. It's a tool built for a different trade.

ito is version control rebuilt from scratch. It's simple enough to explain in a paragraph, and the one thing it does that nothing else does is capture why.

Why, Not Just What

Every version control system tells you what changed. ito also records why. In ito, the unit of work is called a moment, and every moment requires an intent — a plain-English explanation of the purpose of the change.

$ ito log "narrowed indemnification to exclude consequential damages per client instruction"

That's it. One command. The entire state of your document is saved, timestamped, and tagged with who made the change and why. You can't accidentally skip the why — ito won't save without it.

This matters in legal work for reasons it doesn't in most other fields. The why behind a contract change is often more important than the change itself. Six months later, when opposing counsel asks why a liability cap was lowered from $5M to $2M, the answer shouldn't require digging through email or hoping someone remembers. It should be in the record, attached to the exact version where it changed.

That's a complete audit trail. Every change, every reason, every author, every date. Searchable. Not buried in Track Changes bubbles or scattered across seven copies of the same file.

What You Get

Undo

You accepted a redline you shouldn't have. With filenames, you hope you still have the previous copy and that it's actually the right one. With ito:

$ ito undo
undone  f882d03  "incorporated opposing counsel redlines from Jan 24 email"
✓ your files are back — nothing is ever deleted

The redlines are gone. The document is exactly as it was before you incorporated them. The undone version still exists in ito — nothing is ever deleted. If you change your mind, you can restore it.

Search

Six months into litigation, you need to know when and why the non-compete radius was changed from 50 miles to 25 miles.

$ ito search "non-compete"
c8d9e0f  2025-09-14  (JS)
         reduced non-compete radius from 50mi to 25mi — client concerned about enforceability in California

The answer, the date, the author, and the reasoning. Found in seconds, not hours.

Branches

Opposing counsel wants a version with arbitration instead of litigation for dispute resolution. You want to keep your current version too. Don't save a copy with a new filename. Branch it.

$ ito on arbitration-version
now on new branch 'arbitration-version'

# make the arbitration changes...
$ ito log "replaced litigation clause with AAA arbitration per opposing counsel request"

# switch back to the original
$ ito on trunk
now on 'trunk'

# compare the two versions
$ ito compare arbitration-version

Both versions exist. Both have their own history. You can switch between them instantly. When the client decides which direction to go, you continue on that branch. The other stays forever — you might need it later.

Releases

When a document is finalized and sent — to a client, to opposing counsel, to a court — mark it as a release.

$ ito release "sent-to-opposing-counsel-jan-26"
release sent-to-opposing-counsel-jan-26  a1b2c3d
✓ release is permanent and will sync automatically

Releases are immutable. Nobody can accidentally modify the version you sent to court. If changes are needed after a release, ito requires you to create a new branch first — an explicit, traceable act. You'll always be able to answer "what exactly did we send them on January 26th?" with certainty.

Multiple Authors

ito identifies authors by the AUTHOR environment variable. On a shared machine or with a team workflow, each person sets their name. Every moment records who made it. The history reads like a logbook: KL narrowed the definition on the 18th, JS reduced the cap on the 22nd, KL incorporated redlines on the 25th.

For teams working across machines, ito sync pushes and pulls moments over rsync — the same tool that's been moving files between Unix machines for thirty years. No cloud service. No account. No data leaving your network.

What ito Is Not

ito is not a document editor. You still write in whatever you write in — Word, Google Docs, Markdown, plain text. ito sits underneath, silently tracking every version you choose to save.

ito is not Track Changes. Track Changes shows you the diff within a document. ito captures the whole document at each moment, with intent. They're complementary — use Track Changes for the granular markup, use ito for the high-level revision history and the why.

ito is not a document management system. It doesn't have a server, a login, or a search portal. It's a single command-line tool that stores everything in a .ito folder next to your files. If you can type six words, you can use it.

Adding AI to the Loop

ito keeps the history. toast does the work.

toast is composable AI for the terminal. It reads a .persona file that defines its role and a .tools file that controls what commands it can run. Point it at a document with a prompt, and it edits. Pair it with ito, and every edit is saved with intent and fully reversible.

First-pass review

A senior associate receives a 40-page vendor agreement from opposing counsel. Before reading it line by line, they run a first pass:

$ toast vendor-agreement.md "flag one-sided indemnification, unlimited liability, and missing definitions"

Toast reads the agreement and produces a marked-up version with issues flagged. The associate reviews toast's work, not the raw contract. The human makes the judgment calls — toast did the grinding.

Iterative revision

The same loop that hardens code can tighten a contract. jam's times construct runs toast repeatedly, one improvement per round:

🍞 10 times toast engagement-letter.md "review for ambiguity, tighten language"

Each round, toast reads the current version of the document, finds one issue, fixes it, and logs the change with ito. After ten rounds:

Five substantive changes, each with a reason, each individually reversible. The associate reviews the trail, accepts what's right, undoes what isn't. Toast did ten minutes of work in seconds; the associate spends their time on judgment, not on finding the problems.

Opposing counsel redlines

Pipe in context to make toast's edits targeted:

$ cat opposing-redlines.txt | toast agreement.md "incorporate these redlines where reasonable, flag the rest"
$ ito log "incorporated 5 of 8 opposing redlines, flagged 3 for partner review"

The persona

Toast's behavior is controlled by a .persona file in the project directory. For legal work:

# .persona
You are a contracts attorney. You review and edit legal
documents. Flag ambiguous terms, missing definitions,
one-sided provisions, and unlimited liability. Suggest
specific replacement language. One issue per round in
autonomous mode. Use ito to save each change with intent.
Be conservative — when in doubt, flag for human review
rather than making the change.

The last line matters. In legal work, the AI should flag aggressively and change conservatively. The persona enforces that — toast will identify the issue and propose language, but the human decides. Every change is in ito history, so nothing happens silently.

For Legal Ops and IT

ito is a single compiled binary, ~1,100 lines of C, no dependencies. It runs on macOS and Linux. Everything is stored locally in a .ito directory — content-addressed objects (SHA-256), branch pointers, and releases. No database, no service, no daemon.

Sync between machines uses rsync over SSH. Objects are immutable and content-addressed, so sync is append-only and idempotent — safe to run on a cron job. Releases propagate automatically. Branch conflicts are detected and flagged for manual resolution.

toast adds AI-assisted editing and iterative revision loops. But ito stands alone — it doesn't require toast. It doesn't require anything except the documents you're already writing.

ito is a single C file with zero dependencies. Every version is stored locally. Nothing leaves your machine unless you tell it to. linuxtoaster.com