Everything you get with TOVIO.

1. Undo what you did locally. Made a mistake? tovio undo. Changed your mind? tovio redo. It covers supported mutations retained in your local op-log — it can't recall what a teammate already pulled, or reverse an effect outside the repository.

   Every supported local mutation — commits, rebases, lane deletions, resolutions — is recorded in an operation log, and undo walks it back one step at a time. Explicitly irreversible operations, like obliterating a secret, are excluded on purpose. Technical tour →

2. No staging area, no git add ritual. Your work is captured automatically as you go — committing is one step, not three.

   There is no index to forget. The working copy folds into your current change continuously, and you shape granularity afterwards with explicit split, absorb, and amend — instead of curating a staging area up front. Coming from Git →

3. Work is snapshotted before you commit. The working copy folds into your current change continuously, so a crash or a bad command can't eat your afternoon.

   Because the snapshot happens as you work — not when you remember to commit — the "I lost two hours of uncommitted changes" failure mode largely disappears. Committing just names and seals what the system already holds.

4. Read any past version of a file, and reset one file to its committed version — a command each.

   Every version of every tracked file is a content-addressed, verified object. tovio cat --at <rev> prints a path as of any change, commit, or lane, and tovio restore throws away uncommitted edits to a single file — no branch surgery, no detached heads.

5. A local log of the operations you run, so “what did I just do?” always has an answer.

   The op-log is the same record that powers undo: a private, local, ordered history of the repository operations you performed. It stays on your machine — it is not synced or shared.

6. Truly remove sensitive mistakes. Committed a secret? Obliterate it from history for real — not the Git version where it lives on in a reflog somewhere.

   Obliteration is an intentional, audited operation: the payload is removed and replaced with a typed, authenticated tombstone, reads return a typed absence instead of an error, and the removal propagates through sync so copies converge on gone. Secrets in Git, and the fix →

1. Conflicts don't block you. In Git a conflict halts everything until it's fixed. In TOVIO a conflict is a saved, first-class object — commit it, keep working, resolve when you're ready.

   Conflicts are typed, addressed objects that can be stored, synced, and reviewed like anything else. A repository with open conflicts is a valid, fully operational state: commits, switches, and syncs all keep working around it. Technical tour →

2. A guided, interactive resolver that walks you through each conflict.

   Instead of hunting for <<<<<<< markers across the tree, the resolver presents each conflict one at a time — both sides, the base, and your choices — and records the resolution as an ordinary change.

3. TOVIO remembers your resolutions and re-applies the same fix when the same conflict comes back.

   Because a conflict is an addressed object, its resolution can be recognized when the same collision recurs — during a rebase, a repeated merge, a long-lived integration lane — and applied again instead of asking you twice.

4. Merges that understand intent. TOVIO records the edits you actually made — not just before/after text — so merges produce fewer bogus conflicts.

   Git reconstructs your intent from two snapshots and often guesses wrong. TOVIO's change model keeps the edit itself, so operations like "moved this block" and "changed that line" compose instead of colliding.

5. Merge any number of lanes at once into a single clean, multi-parent commit.

   The commit DAG is natively multi-parent, so integrating several lanes is one merge with one result — not a chain of pairwise merges each of which can conflict separately.

6. Region-level merging, with a code-aware second opinion. Two people editing different parts of one file compose instead of colliding.

   The three-way merge works at region level, so non-overlapping edits to the same file compose and only real overlaps become conflicts. On top of that the symbol graph contributes advisory semantic conflicts that a landing gate can weigh — advisory by design: the semantic layer never blocks a core operation. Semantic layer →

7. A conflicts dashboard showing everything unresolved across the project at a glance.

   Because conflicts are stored objects rather than transient working-tree state, they can be listed, filtered, and watched project-wide — so "what's still unresolved?" is a query, not an archaeology dig.

1. A small command surface — seventeen everyday commands instead of Git's twenty-plus, each doing one understandable thing.

   The CLI is governed by a hard rule: to add a command, remove or merge one. That keeps the everyday surface — init, status, commit, log, diff, lane, switch, land, and friends — small enough to actually learn.

2. Speaks Git while you transition. Muscle memory like add, checkout, and stash still works as aliases.

   Git-compat aliases map the commands your fingers already know onto their TOVIO equivalents, and tell you what they mapped to — so the transition teaches instead of punishing. Migration guide →

3. Fast where it matters. Warm status checks are engineered around a filesystem monitor instead of a full rescan — built to stay quick even on very large repositories.

   Instead of walking the whole tree on every status, TOVIO watches what changed since last time — so the cost of the hot path tracks your edits, not the size of the repository.

4. Huge files just work. Videos, models, design files, game assets — no LFS plugin, no separate storage, no surprise bills. Binaries ride the same verified path as source.

   Content-defined chunking (FastCDC) splits large files into deduplicated chunks that live in the same verified object store as your source — a localized edit re-stores only the changed chunks, and there is no separate large-file service to configure or pay for. Binary assets →

5. Built-in explain and quickstart commands that teach you as you go.

   Help lives in the tool, in context — explain answers "what is this concept and why does it matter here," and quickstart walks a new user through their first repository. Tutorial →

6. Friendly errors. Errors carry a stable code, a plain-English description, and a “here's how to fix it.”

   Every error in the catalog has a stable TVO-<AREA>-<NNN> code, a description, and a remediation — so an error message is searchable, scriptable, and actionable instead of a stack trace.

7. JSON output and quiet mode on the CLI for scripting and automation.

   Every command supports default, --quiet, and --json output modes, so scripts and humans get the same answers — one machine-readable, one legible.

8. Shell tab completion out of the box.

   Completions for the major shells ship with the CLI, along with a prompt segment that shows your current lane and change — no third-party plugin required.

9. Work on just part of a huge repo. Check out only the folders you need — the rest never touches your disk.

   Sparse checkout is a first-class profile, not a bolt-on: the path scope you choose is respected end to end, including on pull, so a giant monorepo can feel like a small project on your machine.

10. Ignore rules that make sense. Hidden files and dotfiles are ignored by default, so junk doesn't sneak into commits.

    .tovioignore works the way you'd expect, with sane defaults — and one deliberate precedence rule: permission policy always wins over ignore rules, so a protected path can never be accidentally excluded from protection.

1. Changes keep their identity forever. Rebase, amend, absorb, split — the change keeps its stable id, so links, reviews, and discussions never go stale.

   Every change gets a random 128-bit chg: id that is deliberately distinct from the commit hash. The hash changes when history is rewritten; the change id does not — so reviews, links, and CI results follow the work, not the bytes. Change identity, explained →

2. Split one messy change into several clean ones, or absorb a fix into the change it belongs to.

   Because there is no staging area, granularity is shaped after the fact: split carves one change into several, and absorb routes a small fix into the earlier change it logically belongs to — no interactive-rebase gymnastics.

3. Blame, bisect, cherry-pick, revert — the history tools you rely on, minus the foot-guns.

   The classics are all here, built on the change model — so a cherry-picked change keeps its identity, and a revert is a recorded, undoable operation rather than a mystery commit.

4. Search history for when a line of code appeared or vanished.

   Ask history when a string or symbol first appeared or last vanished, scoped to paths or lanes — the "when did this break" question, answered without checking out anything.

5. Tamper-evident storage. Objects are re-verified when read and when received, so corruption or tampering surfaces immediately instead of festering for years.

   Every object is content-addressed with BLAKE3 and re-hashed on every read and every receipt — a hard rule of the system. A flipped bit on disk or a tampered object in transit is surfaced the moment it's touched, not years later. Security model →

6. Tags that can never be moved — a release marker means what it says, permanently.

   Tags are immutable by design. Unlike Git, where a tag can be silently re-pointed, a TOVIO release marker is a permanent claim — which is what makes it worth signing and auditing.

1. Per-file access control. Decide who can read or change each file or folder.

   Policy is declared per path — a file, a folder, a glob — and travels with the repository as a versioned object. Who can read what is a property of the data itself, not of whichever server happens to host it. How the crypto works →

2. Enforced by cryptography, not trust. Protected paths are encrypted — a server bug or a stolen laptop can't leak content nobody wrapped a key for.

   Each protected object's content is encrypted under its own data key, and that key is wrapped only to authorized recipients. A store, a peer, or an unauthorized clone holds ciphertext it simply cannot open — there is no server rule to bypass, because there is no rule, just math.

3. Grant and revoke access in one command, any time.

   Grant adds a key-wrap for the new recipient; revoke rotates the data key so future content is sealed away from them. Both are one command, recorded in the audit chain.

4. A built-in request-access flow — teammates ask, you approve, done.

   When someone hits a protected path they can't read, the system gives them a request path instead of a dead end — the owner sees the request, approves it, and the grant lands without anyone exchanging keys by hand.

5. Scales from solo to enterprise. Zero setup for individuals, team key management as you grow, with an enterprise attribute-based tier that has passed its conformance gate and remains gated until its release evidence completes.

   Three tiers, one model: Tier 0 (solo) works with no key server at all; Tier 1 (team) adds a Key Authority that manages recipients for you; Tier 2 (enterprise) evaluates attribute-based policy in the cryptography itself. You move up when your team does — the repository format doesn't change. Pricing →

6. Encrypted the instant it's saved. Protected content is sealed at snapshot time, so plaintext never lands in the tracked tree at all.

   Policy paths are matched and encrypted the moment the working copy is snapshotted — before the content ever becomes a tracked object. There is no window where plaintext sits in history waiting to be encrypted later.

7. Contractor-safe repos. Give outside collaborators exactly the folders they need — they can't even sync the rest.

   Path-scoped sync composes with path-scoped permissions: an outside collaborator's clone contains only what they're allowed, and protected content outside their grant never reaches their machine — not even as ciphertext they'd have to trust themselves not to keep.

8. A signed, tamper-evident audit trail per person, verifiable by anyone you share it with.

   Each actor's security-relevant actions form a hash-chained, signed audit log. Verification runs offline — hand the chain to an auditor and they can check it without trusting you or your server. Security model →

9. Extra clearance for the most sensitive files, checked when writing and before protected reads.

   Beyond path permissions, individual objects can require an explicit clearance bit. An identity — human or agent — without clearance is refused at seal time and never has a key wrapped for the protected read, so the check can't be raced or skipped.

10. Require signed commits with one policy setting.

    Turn it on and unsigned work simply doesn't land. Because identity is already a keypair, signing is the default posture — not an optional ceremony bolted on afterwards.

11. Keys live in your OS keychain — never in the repository, never on the server.

    A hard rule of the system: no key material ever enters the synced object store. Private keys live encrypted at rest behind your operating system's keychain, on your device, full stop.

12. Rotation, renewal, and recovery paths for keys — including when someone leaves the team.

    Keys age, laptops die, people leave. Rotation and renewal are routine commands, revocation rotates data keys away from departed members, and recovery paths exist so a lost key isn't lost work.

1. You are a keypair, not a password. Each device you use is enrolled and approved — a phished password can't impersonate you.

   Identity is cryptographic from the start: each device holds its own enrolled key, and everything you do is attributable to a key you provably control. There is no password to phish, reuse, or leak.

2. See and revoke your devices — lost laptop, one command, it's out.

   Your devices are a list you can read and edit. Revoking one cuts that key out of your identity immediately — the lost laptop keeps its ciphertext and loses its access.

3. Passkeys and security keys for the web surface, with step-up verification for dangerous actions like approving a deploy.

   The web surface authenticates with WebAuthn — passkeys and hardware keys — and the most dangerous actions demand a fresh step-up touch, so a hijacked browser session can't quietly approve a production deploy.

4. A verifiable log of identity keys. The system can prove nobody swapped in a fake key for a teammate — and your client refuses to proceed if the proof doesn't check out.

   Key changes append to a transparency log your client actually checks. A server that tried to slip in a substitute key for a teammate would break the proof — and your client treats a broken proof as a hard stop, not a warning.

5. Sign in with your company identity (OIDC) when you're on a team.

   Team sign-in federates with your existing identity provider over OIDC, so joining a TOVIO org doesn't mean a new credential — and leaving the company means leaving the repos. For teams →

1. Hand an agent a scoped token, not your keys. It gets the clear code and none of your protected paths, for exactly as long as you allow.

   A capability token bounds an agent by path, operation, lane, and a hard expiry — tovio agent new claude --model claude --task "api work" --expires-in 8 issues one with the safe default: every clear path, every policy-protected path excluded, no escalation, no secret clearance. The agent control plane →

2. Enforced before anything is sealed — an out-of-scope agent commit is refused, period.

   Scope is checked before a commit is sealed and before a protected read is served — not audited after the fact. An out-of-scope write never becomes history, and an out-of-scope read is rejected before any decryption is attempted.

3. Revoke an agent's access without waiting for its token to expire.

   Expiry is the backstop, not the only exit. A misbehaving agent's token can be revoked immediately, and every operation it already performed remains attributed to it in provenance.

4. Agents work in their own namespace, so their experiments can't clutter or clobber your lanes.

   Agent work lives under agent/<name>/** lanes by default. Your main and your feature lanes stay yours; the agent's drafts stay legible, listable, and out of the way until you decide they're worth keeping.

5. Promote agent work when it's good, abandon it when it's not — one command each.

   agent promote lifts an agent's lane into your normal flow; agent abandon closes it out cleanly. Either way the decision is explicit, recorded, and yours.

6. AI-authored changes carry signed provenance — which agent, which task, which model, delegated by whom.

   Every agent-authored commit carries signed provenance: the agent, the task, the model, the tool manifest it ran with, and the authorizing context that let it act. "Where did this code come from" has a cryptographic answer.

7. Filter history by agent or task — “show me what the refactor bot did last week.”

   tovio log --entity claude --task-id T-1421 — history is queryable by who (or what) did the work and under which task, because provenance is structured data, not a commit-message convention.

8. Agents declare intent before starting, so two agents — or an agent and you — don't stomp the same files.

   agent intent announces what an agent is about to touch. Other agents — and you — see declared intents before starting overlapping work, turning silent collisions into visible coordination.

9. Designed for fleets. Coordination context is part of the system, aimed at many agents working one repository without chaos.

   Intents, namespaced lanes, scoped tokens, and shared coordination context are one coherent design: many agents on one repository, each with a visible footprint and bounded authority, rather than a pile of bots sharing your credentials.

10. Delegation chains. An agent can hand a strictly narrower sub-task to another agent, and the whole authorization chain is recorded.

    A sub-token can only ever narrow — smaller scope, shorter life, never more authority than its parent. The full delegation chain rides along in the provenance of the resulting commits, so a three-agent pipeline is still one auditable line of authority.

11. Works with your AI tools today. A built-in MCP server lets Claude and other assistants read and write the repo under the same rules.

    The MCP server speaks stdio or HTTP (loopback by default; a bearer secret is required to bind anywhere else) and validates the agent's token on every operation — so your assistant works the repo under exactly the leash you issued. Integrations →

12. A Node.js SDK for building your own integrations.

    The SDK exposes reads and token-scoped writes to TypeScript and JavaScript, backed by the same native engine as the CLI — build a bot, a dashboard, or a custom workflow without shelling out to a binary.

13. Capture agent session transcripts alongside the changes they produced — clearly marked as unattested context, so you can review how the code came to be.

    The conversation that produced a change can be stored next to the change itself — explicitly labeled as unattested context, distinct from the signed provenance. Reviewers see not just what the agent changed, but the reasoning trail behind it.

1. Snapshot an AI system's behavior — prompts, model, settings — as a versioned object.

   The Behavioral Version Registry captures the full behavioral surface of an AI system — prompts, model identifier, parameters, tool configuration — as one addressed, versioned object, so "what exactly was running last Tuesday" has a precise answer.

2. Diff two behavioral versions to see exactly what changed between “it worked” and “it's weird now.”

   A behavioral diff shows what actually changed — a prompt edit, a model bump, a temperature tweak — with an assessment of how risky the delta is, instead of leaving you to eyeball two config files.

3. Roll back to a known-good behavior in one command.

   Because behavior is versioned like code, rollback is just checking out a known-good behavioral version — no scavenger hunt through deploy logs and chat history for the settings that used to work.

1. Refs that converge instead of colliding. Two people advancing a lane “at the same time” resolves cleanly by design, not by whoever pushed last.

   Lane pointers propagate as CRDTs over a hybrid logical clock, so concurrent updates converge deterministically on every machine. "The remote has work you don't" is never an error — the divergence reconciles into an honest two-parent commit on the lane. How this compares →

2. Proposals instead of pull requests — the same idea, tied to change identity, so a rebase never orphans the review.

   A proposal follows the chg: id, not the commit hash — rebase, amend, or absorb the work and the review thread, approvals, and CI history stay attached to it. Change identity →

3. Stacked proposals. Build change B on change A, review both in parallel, land in order — the dependency tracking is automatic.

   Dependent changes form an explicit stack the system understands: reviewers see each change on its own, and landing respects the order without you rebasing the stack by hand after every approval.

4. A merge queue that lands approved work in order without the rebase-wait-rebase treadmill.

   Approved changes queue up and land in sequence, each validated against the tip it will actually land on — so nobody spends their afternoon rebasing onto a main lane that moved again while CI ran.

5. Reviews, checks, and CI status attached to the change and visible everywhere it appears.

   Because they hang off the stable change id, reviews and check results show up wherever the change does — CLI, web, editor — and survive every rewrite of the underlying commits.

6. Real file locking for the un-mergeable stuff — design files, spreadsheets, binaries. Take a lock, teammates see it, admins can break a stale one.

   Lock grants are arbitrated by the server — one holder at a time — and visible to every client, so two people don't silently produce two versions of an un-mergeable file. Admins can break a lock someone left behind on vacation.

7. Coordinate changes across repositories. Group related changes into one meta-change and land them together.

   A meta-change groups related changes across repositories and lands them as a unit, through durable reservations and a signed prepare/commit/release sequence — so a cross-repo refactor doesn't strand half-landed.

8. Follow a change as it moves — new revisions, approvals, checks, landing — off the Forge's live event stream.

   Every proposal and check transition is a first-class event on the Forge's cursored SSE feed, so a client, a bot, or a chat integration can track one change without polling a web page. Per-recipient notification delivery today covers hosted account lifecycle; anything richer is built on that feed.

9. Webhooks and live event streams to wire into chat, dashboards, anything.

   The Forge emits its event stream over webhooks and live server-sent events, so chat notifications, deploy triggers, and custom dashboards consume the same first-class feed.

10. A personal home and inbox — the changes waiting on you, in one place.

    One view of everything that needs you: reviews you owe, proposals you authored that moved, requests waiting on your approval — instead of reconstructing your to-do list from notification emails.

1. Fast, secure sync — clone, push, pull over modern encrypted connections.

   Native and HTTPS-framed sync run over TLS 1.3 with a channel-bound identity proof on connect — your keypair, not a password or a bearer token, is what the server trusts.

2. Continuous background sync if you want it, so the repo stays current without you thinking about it.

   Background sync is opportunistic and throttled, never materializes changes over a dirty working copy, and lets you choose what gets pushed — off, shared lanes only, or everything. A watch mode keeps a long-running repo continuously current.

3. Divergence heals itself. If two machines drift, sync reconciles them into an honest merge instead of leaving you to untangle it.

   When two machines advance the same lane, pull reconciles the drift on the lane — a clean merge when the changes compose, a first-class conflict object when they don't. Nothing is orphaned, and every side of the divergence stays in history.

4. Partial clone for giant repos — fetch history lazily and start working in seconds.

   Full, sparse, shallow, partial, and lazy fetch-on-read profiles are all explicit choices — clone what you need now, and let the rest arrive on demand when something actually reads it.

5. Offline-first. History, lanes, even permission checks work with no network. Sync when you're back.

   The engine is local-first; the network is a profile, not a precondition. Commits, merges, history, undo, and cryptographic permission checks all run on the plane — sync is the thing you do when you land.

1. Import a Git repository in one command — history, branches, tags preserved.

   The importer walks your Git history and rebuilds it natively: every change gets a fresh Change ID, and the original Git hash is preserved alongside it so old references still resolve. Migration guide →

2. A two-way Git bridge, so teammates still on Git keep working while you migrate gradually.

   The bridge syncs both directions with GitHub, GitLab, and Gitea through an explicit, namespaced mapping — half the team can move today while the other half keeps pushing to Git, and nobody's work is stranded.

3. Existing Git tooling can talk to a TOVIO server over Git's own HTTP protocol for compatibility.

   A stock git clone works against a TOVIO server over Git's smart-HTTP protocol, serving a materialized view with refs filtered by policy — and protected content stays ciphertext even to a Git client.

4. Export back to Git when you need to. The format is specified and open — no lock-in.

   One-shot export produces a normal Git repository; policy-protected objects are excluded or emitted as ciphertext, with a warning either way. The storage format itself is openly specified, so your data is never hostage to the tool. Open source & the spec →

1. TOVIO reads your code's structure — functions, classes, references — in Rust, TypeScript/JavaScript, Python, and Go, automatically.

   A symbol graph — functions, types, call edges, test edges — is built by default for the supported languages, with no server, no language plugin, and no separate indexing service to run.

2. Semantic diff. See “renamed this function, changed that signature” instead of a wall of plus and minus lines.

   tovio semantic diff reports what changed structurally — functions added, removed, and modified, and which interface changes are breaking — so reviewing a refactor means reading intent, not reconstructing it from line noise.

3. Jump to a symbol's definition or references across your history.

   Because the graph is versioned with the code, symbol navigation works across history too — where a function is defined, who calls it, and how that answer looked three months ago.

4. Landing checks that understand code, so refactors Git would flag as conflicts sail through.

   Landing gates can weigh advisory semantic conflicts alongside textual ones — two edits to different symbols compose, while a genuine semantic collision is surfaced before it lands, not after it breaks the build.

5. The index respects permissions too — files you can't read don't leak through search.

   Symbols from protected files live in sealed shards inside the same crypto boundary as the files themselves — so the semantic layer can never be used as a side door around a permission you don't hold.

1. A CI/CD engine in the platform — no separate service to buy, configure, and secure.

   Pipelines, results, and deploy history live in the same system as your code and reviews — one identity model, one permission model, one audit trail, zero webhooked third-party attack surface. Job execution itself is not shipped: no runner substrate is provisioned yet.

2. Pipelines defined in typed code, not fragile YAML — with type errors caught before you push.

   A pipeline is a typed program, so a misspelled field or an impossible wiring is a compile error on your machine — not a twenty-minute red build discovered after you pushed.

3. Each CI job is issued its own short-lived, narrowly scoped credential.

   The same capability tokens that leash agents leash CI: the orchestrator mints a fresh token per job, scoped to the change's own paths, read-only, with no secret clearance, expiring with the job. Minting is built; because no substrate executes jobs yet, nothing has consumed one in production.

4. Deployment approvals with hardware-key step-up — production deploys require a human touching a security key.

   A production deploy waits for a fresh WebAuthn step-up — a human, physically touching a security key, at approval time. A stolen session or a compromised laptop can't ship to production on its own.

5. Pipeline dashboards — job graphs and deployment history, in the review surface.

   The job graph, gate states and deployment history render from the same web surface where the change was reviewed. These views currently read demo data behind a documented live-Forge seam, and job logs are not yet stored or served.

6. CI results gate landing — red or unapproved changes don't reach the main lane.

   Check results attach to the change and the landing path enforces them: a change that is red, unapproved, or short of its required reviewers doesn't land, no matter who pushes the button.

1. Plugins that can't go rogue. Plugins are sandboxed WebAssembly with explicitly granted capabilities — no file or network access unless you grant it.

   Plugins run in a WebAssembly sandbox and start with nothing: file access, network access, and every other capability is an explicit grant you make when installing. A plugin can only do what its manifest asked for and you approved.

2. Signed and verified plugins, with a trust store you control.

   Plugins are signed, verified before they load, and admitted by a trust store you own — so "where did this plugin come from and has it changed" is checked by the system, not by hoping.

3. A built-in secret scanner with hundreds of rules that catches leaked keys and passwords before they land.

   Secret scanning ships in the box and runs in the commit and landing path — API keys, tokens, and passwords are caught before they become history, which matters, because history is the hard part to clean. Why secrets in Git are forever →

4. Policy hooks — enforce your team's rules automatically at land time.

   Lifecycle hooks run at snapshot and land — lint gates, license checks, custom resolvers, whatever your team's rules are — inside the same sandbox, so enforcement is automatic and the hooks themselves can't go rogue.

1. A full-featured VS Code extension.

   Status, diff, lanes, conflict resolution, history, and agent-token management — the everyday workflow, native in the editor most teams already live in. Start with early access →

2. A JetBrains plugin for the IntelliJ family.

   The same everyday workflow for IntelliJ-family IDEs. Per-surface availability during the pre-alpha is tracked openly on the status page →

3. A native desktop app, growing to full public-CLI parity.

   A graphical client for people who don't live in a terminal, under the deliberate rule that anything the CLI can do the app should do. That migration is in progress and tracked as an inventory, not a finished claim: every public CLI leaf is classified and a drifted one fails CI, while the commands themselves move across one at a time. Status page →

4. A fast web interface — browse code, review proposals, manage access, watch CI from a browser.

   The web surface covers browsing, review, access management, and CI monitoring — and you can try the public side of it right now in the public explorer →

5. Sensitive files stay encrypted even in the browser. Decryption happens on your machine with your key; the server doesn't see plaintext.

   The web client decrypts protected content locally, with your key, in your browser. The server serves ciphertext and never holds what it would take to read it — the same trust boundary as the CLI, kept in the browser too.

6. Disposable workspaces — spin up a sandboxed copy of the repo to test something, throw it away after.

   Try the risky idea in a sandboxed working copy materialized from the same object store — admission-bounded, isolated while it lives, and reclaimed through a crash-recoverable journal that re-seals any protected edits and can promote what you keep onto a lane. Container and micro-VM execution inside one is still a follow-on.

1. Run the whole server inside your perimeter — it's a single binary, licensed commercially.

   The Forge — sync, proposals, reviews, events, audit, admin — is one binary that runs on your own hardware, behind your own firewall, with connection ACLs and authenticated APIs built in. It is a commercial product, available to dedicated enterprises under agreement. On-premise guide →

2. TOVIO Cloud runs the same verified engine distributed across a global edge network — gated until its hosting evidence is complete. One engine, no fork: hosted and on-premise share the same domain logic and can't drift apart.

   The hosted service runs the same engine as the on-premise Forge, distributed across a global edge network — locks, refs, and proposal transitions stay strongly consistent throughout. Because both surfaces share one codebase, a fix in one is a fix in both. Hosting status →

3. Admin tools included — user management, org roles, backups, metrics, retention, rate limiting.

   The operational surface ships with the server: users and org roles, backup and restore, metrics, retention policies, and rate limiting — not a wiki page of scripts you write yourself.

4. High availability and replication for teams that can't afford downtime.

   Replication keeps multiple servers converged — the same reconciliation machinery that heals two laptops heals two replicas — so losing a node is an inconvenience, not an outage.

5. Land across two servers — repositories on separate Forges can be changed together, each instance authenticating the other.

   Cross-Forge meta-land groups repositories that live on different instances into one change and lands it as a unit, through durable single-writer reservations and a signed prepare / commit / release handshake. Each server keeps its own keys and governance. Note that "federation" elsewhere in TOVIO means identity-provider federation (SAML/OIDC/SCIM), not a general server-to-server product.

6. Engineered for enormous monorepos — hot paths are designed so cost tracks what changed, not how big the repo is.

   Status watches the filesystem instead of rescanning it, chunking re-stores only what changed, and sparse and lazy profiles keep the unused majority of a monorepo off your disk — the design principle throughout is that cost follows your edit, not the repository's size.

1. SSO with SAML and OIDC, plus WorkOS support — built, and gated until its live-provider evidence lands.

   Enterprise sign-in federates with the identity provider you already run — SAML or OIDC directly, or through WorkOS — so access to code follows the same front door as everything else. The connectors are implemented; live-provider and credential-rotation evidence is one of the open hosted gates, so this is not a capability you can buy today. Enterprise solutions →

2. Automatic provisioning from your directory (SCIM/LDAP) — joiners and leavers gain and lose access automatically.

   Directory sync via SCIM or LDAP makes the roster authoritative: a new hire has access on day one, and a departure revokes it without anyone remembering to — the joiner/mover/leaver flow your auditors ask about, automated. The reconcile loop and both enumerators are built end to end; like SSO above, they wait on live-directory evidence before they are sold.

3. Attribute-based encryption policies — the enterprise tier evaluates policy in the cryptography itself. It has passed its conformance gate and stays private and default-off until the remaining release evidence completes.

   In the enterprise tier, the policy expression — team, role, clearance — is evaluated by the cryptography at decrypt time (CP-ABE), not by a server consulting a table. A rule like "Payments, clearance 2" is a property of the ciphertext itself. Current gating →

4. KMS and HSM integration paths for key custody in regulated environments.

   For environments where key custody is regulated, the key-authority design carries defined integration paths to KMS and HSM backends — see the roadmap → for where these sit in the enterprise train.

5. Org-wide governance policies that individual repos can tighten but never loosen.

   Governance composes one way only: the organization sets the floor — required reviews, signing, retention — and a repository may add stricter rules on top, but can never opt out of the baseline.

6. Exportable, independently verifiable audit archives for compliance.

   The signed, hash-chained audit trail exports as an archive your auditor can verify independently — the chain proves its own integrity, without trusting you, your server, or your vendor. Compliance →

1. Open core. The engine, CLI, SDKs, and the full specification are Apache-2.0. The format is documented, so your data is never hostage.

   The engine, CLI, SDKs, and the complete storage and protocol specification are Apache-2.0; the Forge is the commercial product. Anyone can implement the format from the spec alone — that's the point. Open source →

2. Deterministic by design. The same content always produces the same repository bytes — which is what makes the cryptographic guarantees possible.

   Structured objects are encoded in deterministic CBOR and addressed by BLAKE3, validated against a conformance corpus. Determinism isn't pedantry — content addressing, verification, and the audit chain all depend on it.

3. Implemented and tested. The capabilities above are built in the codebase under their documented supported profiles — this page was drawn from the implementation, not a roadmap.

   Each capability on this page corresponds to implemented, tested code under its documented supported profile. Where a boundary or caveat exists, it's stated in the item — that honesty is deliberate. The one section that is explicitly not a shipped runtime is CI/CD job execution, marked as such above. Status page →

4. Still pre-alpha. There has been no general-availability release, so some features may not yet be fully functional in every environment, and surfaces can still change before release.

   "Implemented" and "released" are different claims, and we only make the first one today. Command names, formats at the edges, and per-platform availability can still shift before general availability.

5. Still open, stated plainly: independent third-party security review, published scale evidence at the declared ceilings, signed public packages, and hosted-service productization. TOVIO's own status page tracks this openly rather than hiding it.

   These are the release gates we hold ourselves to before asking for production trust: an external audit of the security-critical code, scale and failure evidence at the declared ceilings, signed packages you can verify, and a productized hosted service. Roadmap →

Phases 0-4 are implementation-complete under their documented profiles. Phase 5 productization, publication, hosted-service, Tier-2 Enterprise, and independent evidence remain in progress. See the status page androadmap for the current gates.