Atlas

The whole system, drawn.

Five diagrams and a walkthrough, for a reader who wants the mechanism rather than the pitch: where a change goes when you commit it, what happens when a protected file is read, what an agent can and cannot reach, and how two divergent tips reconcile.

Everything you get →Coming from Git?Open the documentation

Colour carries meaning in every diagram below acid — you, the human path amber — agents pink — refusals and conflicts blue — review and the Forge

Why it is shaped this way

Three assumptions that stopped holding.

Git was designed when every committer was a careful human and read access was all-or-nothing per repository. Each gap below is answered in the architecture rather than worked around in process.

01 · AGENTS

Automation needs bounded authority

A model that assumes one deliberate human author per commit has no way to express “this agent may touch frontend code but never secrets”, and no way to record which model, task or person stood behind a change.

02 · PRIVACY

The permission boundary is the repository

You cannot say “this person reads the source but not the production configuration”. Every workaround — split repositories, submodules, external secret managers — routes around the version control system rather than through it.

03 · IDENTITY

Rewriting severs work from itself

When a commit's identity is its hash, an amend or a rebase produces a different object with no record that it is the same work — so review threads, automation and provenance lose their subject exactly when history moves.

The mental model

Seven concepts, and three of them stay hidden until you need them.

Write no policy and you never meet encryption, keys or a Key Authority. Register no agent and capability tokens never appear. The everyday surface is the first four.

Identity Who is acting.

Every actor — you, a teammate, an agent, a CI runner — is a keypair, created silently at init. There is no anonymous actor, so a protected read is attributable.

Like An SSH key TOVIO manages for you.

Change A unit of work.

Named chg:xkqm7y — random, and stable across the supported rewrite operations. You live in a change; there is no staging area and no add step.

Like A branch and its commits as one named unit, with a tracking number.

Commit A saved snapshot.

Immutable and content-hashed, carrying the Change ID of the work that produced it. The hash moves when content moves; the change's name does not.

Like A Git commit, plus a stable owner.

Conflict A question the repo holds.

Stored as a typed object, so the merge completes and work continues. Resolving it once propagates to contexts sharing the same conflict signature.

Like A type error rather than a crash — but landing onto a protected lane still refuses it.

Policy Who may read a path.

Attach a rule to a path and files there are encrypted at snapshot time. You declare who should be able to read; key handling is not yours to manage.

Like A secrets manager that lives in the repository.

Capability What an agent may do.

A signed, expiring token naming the paths an agent may touch, the operations it may perform, and whether it carries secret clearance.

Like A fine-grained access token, scoped to paths and tied to an agent identity.

Forge Where people share.

The optional server for sync, review, locks and audit. It runs inside your perimeter or hosted, and it is not the authority over who may read a file.

Like A code host that is blind to your protected files.

Diagram 01 · the mental flip

Checking in is two verbs, not one.

Git's commit records the snapshot and advances your branch pointer in the same motion. TOVIO separates the two, which is what lets the work keep its name when history is rewritten underneath it.

A change is the unit of work and holds a stable name; a lane is a movable label that finished work lands onto. Because the work owns its identity, review, automation and provenance still resolve to the same change after an amend, rebase, squash or reorder. The split is about which lane moves: committing advances the lane you are on, while landing is what advances a shared one like main.

TOVIO	Closest Git idea	The difference that matters
Change	A branch and its commits as one unit	Stable ID survives the supported rewrites; no staging area
Lane	Branch	A landing target rather than a workspace; propagates as a CRDT ref
Conflict object	Merge markers	Durable data that can be inspected and resolved later
Policy object	Ignored file plus an external secrets manager	Lives in the repository, enforced cryptographically, survives cloning
Capability token	Fine-grained access token	Path-scoped and expiring, with provenance on agent-authorized work
Op-log and undo	Reflog	Covers supported mutations retained locally, not commits alone
sync	push plus pull	One operation; a divergent tip reconciles on the lane
land	Merging a feature in	Integrates a change and cascades the rebase to its descendants
Stacked changes	Branching off a branch	Landing the base rebases the rest, identities unchanged
— none —	The staging area	Removed. The working copy is the current change

These are orientation points, not automatic translations.The migration page goes further →

Diagram 02 · the stack

Seven layers, one pure engine, all input and output at the edge.

The layers are a conceptual decomposition rather than a package layout. The engine performs no I/O, reads no configuration, and reaches for no clock or randomness on its own — every side effect arrives through an injected interface, which is what keeps it deterministic and testable.

Because storage, time, randomness, signing and the Key Authority arrive as interfaces, the same engine runs identically under the CLI, the Forge, the Node bindings and a test harness — and a non-deterministic encoding is a correctness bug rather than a matter of style, because it would break content addressing.

Decisions that are settled

Deterministic serialization for structured objects, raw bytes for payloads.
BLAKE3-256 addressing with content-defined chunking above a size threshold.
Lanes are CRDT refs over a Hybrid Logical Clock; tags are immutable.
Change IDs are random and distinct from commit IDs.
No staging area — the working copy auto-snapshots into the current change.
Every verified object is re-hashed on read and on receipt.

The seam that makes privacy possible

Because the working copy snapshots continuously, policy matching and encryption happen at snapshot time rather than commit time. That single ordering decision is why plaintext for a protected path never lands in a tracked tree, and why the protection survives a full clone by an unauthorized reader.

It is also why the read path needs no server: the decision was made when the object was sealed, not when it is opened.

Walkthrough 01 · commit

What happens between your editor and the lane.

Eight hops. The second is the seam described above; the rest is addressing, signing and durability.

01Walk the working copy — changed paths only, honouring the ignore rules and the tracking index.edge

02Policy match, then encrypt now. A content key is drawn, the payload is sealed, and the recipient set is built — producing a policy object.core

03Files above the chunking threshold are content-defined split into chunks plus a manifest; smaller files become a single blob.core

04Canonical encode, then address by BLAKE3. Unchanged subtrees are reused by address, so identical content is stored once.core

05Build trees bottom-up, then a commit carrying the stable Change ID, its parents, author, and intent or provenance.core

06Sign the canonical payload — the signing key stays in the OS keychain and never enters the engine.edge

07Persist objects durably: temp file, flush, then atomic rename. An address that already exists is a no-op.edge

08Advance the current lane's CRDT register, open the next change, and append the op-log so undo can restore the exact prior state.core

Note the scope of step 08: committing advances the lane you are on. Publishing onto a shared lane such as main is what land does, which is the split the first diagram draws. Speed comes from hashing only what changed, and the repository mutation lock is held across state capture, ref persistence and the audit append — so a second writer cannot fork the transaction midway.

Walkthrough 02 · a protected read

Opening a file the policy protects.

The Key Authority authorizes at grant and seal time. It is not consulted when the file is opened, which is what makes a protected read work offline and makes an untrusted mirror harmless.

The signed audit entry is appended before plaintext is released, and a failed append blocks the release. A compromised host or mirror can serve protected objects indefinitely and still read none of them.

TIER 0 · SOLO

No Key Authority at all

Your own key unwraps the content key directly. A solo user who writes no policy never encounters any of this machinery.

TIER 1 · TEAM

Hybrid envelope

A content key sealed to explicitly named recipients with an authorized wrapped key. The Key Authority guides grants; it is not in the read path.

TIER 2 · ENTERPRISE

Policy in the cryptography

Attribute-based read control, which has passed its enterprise Key Authority conformance and internal review gate. It is default-off and not generally available.

The security model →

Walkthrough 03 · an agent at work

An agent gets a token, not your keys.

Scope is checked before anything is sealed, and a refusal outside clearance is arithmetic rather than policy: with no key wrapped to it, the bytes simply do not open.

The token bounds two separate things, and they refuse at different moments.The read drawn here is outside the token's path scope, so it is refused by the scope check before any policy, key or clearance is consulted — a token refusal, TVO-TOKEN-001. Clearance is the second gate, and it applies to a protected path the agent is scoped to: with no clearance attribute no key was ever wrapped to that agent, so the bytes do not open and the refusal is a permission one such as TVO-PERM-001. An access list refuses a request; a missing key refuses the mathematics.

Runner and tool isolation remain separate operator responsibilities; the token bounds what TOVIO-mediated operations can reach.How agent access works →

Walkthrough 04 · sync

When two tips have diverged.

“The other side has work you do not have” is an ordinary state rather than an error. Pointers propagate as CRDTs, and a genuinely divergent tip reconciles on the lane into a two-parent commit — clean, or carrying a typed conflict object.

The server's authority is deliberately narrow: for writes to policy-governed paths the Forge verifies the write proof and records an audit entry. It enforces writepolicy, and enforces no read access at all — which is why a hosted Forge does not become a new trust root. Authorization, protected-lane and review checks can still refuse a proposed mutation.

The surface

A wide command set that stays out of the way.

Help shows the everyday tier; the team and advanced tiers are one flag away. Advanced power stays invisible until you reach for it.

EVERYDAY

Most days, this is all of it

initquickstartstatuscommitsynclogdiffconflictsmvlaneswitchlandundochangecloneresolvehealth

TEAM

Appears when people do

policyaccessauditidentitykeydeviceagentforgeissuereleasereviewlockunlocklockspushpullfetch

ADVANCED

There when you need it

rebasecherry-pickrevertbisectblamerestoresparsefsmonitorautosynctagciexplainfsckgcsemanticbehavioralpluginmetamcpservegit

Git-compat aliases map familiar verbs onto their TOVIO equivalents and tell you what they mapped to.

Beyond the terminal

MCP server — agent-native reads and writes
Node SDK and native bindings — the same engine from JavaScript
VS Code and JetBrains — over the CLI's structured output contract
Web UI and a local desktop edge — clients of the Forge
CI bridge — wrapper profiles for existing CI systems

Three boundaries, one model

Solo — no server and no Key Authority; permission evaluation included
Peer to peer — every clone is a full peer
Against a Forge — yours under agreement, or hosted once its gates close

The network is an optimization for sync, never a dependency for correctness. Run it yourself →

Status as of 2026-08-03

Implementation is deep; release evidence is still open.

Everything drawn above is built and runnable under its documented supported profile. What remains is largely assurance rather than construction — and none of it is converted into an availability claim here.