Glossary¶

Every TOVIO term, defined once. When you meet an unfamiliar word in the docs, look it up here. Terms are grouped for reading; within each group they are alphabetical.

Version control¶

Branch — See Lane. (Git term; tovio branch is a git-compat alias for tovio lane.)

Buildable state — A working tree (or its materialized view) with no unresolved conflict markers, so it compiles / passes CI. Distinct from a consistent VCS state: a repo with open conflicts is always VCS-consistent but not necessarily buildable. Protected lanes are kept buildable by the landing gate.

Change — A unit of work with a stable identity (its Change ID) that persists through history rewriting. Closer to "a Git branch and its commits as one named unit" than to a bare branch pointer. The identity survives amend / rebase / squash; lanes are landing targets rather than workspaces.

Change ID — A random 128-bit identifier rendered chg:<base32>, assigned when a change is created and preserved across amend, rebase, squash, reorder. Distinct from a Commit ID.

Commit — An immutable, content-addressed snapshot of the working tree plus metadata (author, parents, message, intent, provenance). Identified by its Commit ID.

Commit ID — The BLAKE3 hash of a commit object's canonical bytes (blake3:<hex>). Changes whenever the commit's content changes; distinct from the Change ID.

Conflict object — A first-class stored object representing an unresolved merge: both sides, their common ancestor, the conflicting paths, and a status. A repository with open conflicts is a valid, operational state. Open conflicts are non-blocking for in-flight work but may not land onto a protected lane. "Non-blocking" is scoped to your own stack — pulling a teammate's conflicted change as a dependency is gated (use tovio sync --isolate or wait). Conflicts are typed (content, delete_modify, rename_edit, rename_rename, advisory semantic, …) and resolved per kind.

Draft change — A private, exploratory change (tovio change new --draft) that is not proposable or landable and is invisible to team views until promoted (tovio change promote) or shared. abandon / restore set it aside and recover it without losing history.

Land — To integrate a change onto a lane (tovio land): the lane advances to include the change and the change's descendants are automatically re-based so a stack stays intact. The everyday change→lane integration verb; landing onto a protected lane requires a conflict-free change.

Lane — A named position in history: a CRDT pointer to a commit. In TOVIO a lane is a landing target, not a workspace — you work in changes and tovio land them onto lanes. Contrast Git, where the branch is the thing you work on.

Materialized view — A derived rendering of a tree that contains conflicts, showing each conflicted path as its last-known-clean version (the most recent conflict-free version of that path). Used by tovio build-check and tovio sync --isolate so builds can proceed without resolving. Never stored or hashed.

Merge-base — The DAG lowest common ancestor of the two sides of a merge or rebase: the deterministic three-way base. A criss-cross (multiple LCAs) uses a recorded synthetic base.

Obliteration — The intentional, auditable, permanent removal of an object's payload from the store. The address is preserved as a typed tombstone; reads return TVO-STORE-002, not a 404. See tovio obliterate.

Operation log (op-log) — A local, append-only log of every VCS operation (commit, fetch, rebase, lane delete…). Backs tovio undo / redo. Not synced. Broader than Git's reflog.

Protected lane — A lane (e.g. main, release) designated in the policy manifest as one that must stay conflict-free (buildable); land / push refuse to advance it to a change with unresolved conflicts, and it may carry required checks and a landing write_policy.

Resolution propagation — Resolve a conflict once and the resolution applies wherever that same conflict recurs, survives history rewriting (amend / rebase / squash), and won't come back on a later rebase or re-sync — so you never re-resolve the same conflict (TOVIO's always-on replacement for Git's rerere).

Semantic conflict — A textually-clean but interface-incompatible change: a dependent change still calls a changed API and won't compile. Advisory, surfaced by the optional semantic layer; blocks only if a protected lane requires semantic-check.

Stacked changes — A chain of changes in which each is the parent of the next, used when work depends on earlier work not yet landed (the TOVIO equivalent of "branching off a branch"). Landing an ancestor auto-rebases its descendants.

Staleness — How far a change's base is behind its target lane (commits-behind + age); surfaced by tovio change health / status to warn against long-running rot.

Tree — A directory snapshot mapping names to object addresses (blob / tree / manifest) with metadata.

Working copy — The checked-out directory tree. Continuously and automatically tracked as the current evolving change; there is no staging area.

Storage¶

BLAKE3 — The 256-bit content-hash function TOVIO uses (faster than SHA-256, tree-structured).

Blob — Raw content of a small file (below the chunking threshold), stored and addressed directly.

Canonical (deterministic) encoding — The unique byte representation of a structured object used for hashing: deterministic CBOR.

Chunk — A variable-size, content-defined piece of a large file produced by FastCDC.

Chunk manifest — An object listing the ordered chunk addresses that reconstruct a large file; the file's identity is the manifest's address.

Clear object — An object stored in plaintext, readable by anyone with repository read access.

Content addressing — Identifying an object by the cryptographic hash of its bytes, giving deduplication and tamper-evidence.

FastCDC — Fast Content-Defined Chunking; splits files at rolling-hash boundaries so small edits re-store only changed chunks.

Policy object — An object whose content is encrypted under an access policy (a policy-blob or policy-chunk); readable only by identities whose keys satisfy the policy.

Permissions & cryptography¶

ABE / CP-ABE — Attribute-Based Encryption / Ciphertext-Policy ABE. A scheme where the access policy is embedded in the ciphertext and decryption succeeds iff the reader's attributes satisfy it. TOVIO's Tier 2 implementation has passed its private enterprise KA conformance/internal-review gate but is not generally available; public-client support remains default-off, and threshold/KMS/HSM is a later profile.

ABS — Attribute-Based Signature. Proves the signer holds attributes satisfying a policy without revealing which; used for write-access enforcement.

age — The encryption construction used in Tier 0 (Solo): ephemeral X25519 key agreement + ChaCha20-Poly1305.

Attribute — A signed claim about an identity (role=engineer, team=payments, clearance=secrets), optionally with expiry. Used to evaluate access policies.

DEK (Data Encryption Key) — A per-object random symmetric key (AES-256-GCM) that encrypts content in Tier 1 (Team); wrapped once per authorized recipient.

DID — Decentralized Identifier; the W3C-style identifier an identity may use (did:tovio:…). Surfaced only when collaboration requires it (not in Simple Mode).

Envelope — The container format binding ciphertext to its wrapped keys / policy header. Designed to be ABE-forward: higher tiers add a recipient / header type without changing the object format.

Hybrid encryption — Encrypt content with a fast symmetric cipher (the DEK); protect the DEK with cheap asymmetric operations per recipient. The Tier 1 model.

Identity — A first-class cryptographic principal (human, agent, CI, deployment): an Ed25519 signing key + X25519 key-exchange key, optionally addressed as a DID.

Key Authority (KA) — The entity that decides which identities may read which policy paths. Absent in Solo Mode; an authorization oracle in Team Mode; threshold / KMS-backed in Enterprise Mode.

Policy expression — A boolean expression over attributes (role=engineer & team=payments) declaring who may read or write a path.

Recovery key — An independent key escrowed at init that can restore an identity's decryption access if its private key is lost — data-loss recovery, unique to an encrypted VCS.

Agents¶

Agent — A non-human identity (AI coding agent, CI runner, bot) that participates in TOVIO under a capability token, with entity=agent.

Behavioral version / snapshot — A versioned record of an AI system's full behavioral surface (model, prompts, tools, memory, guardrails), diffable independently of code. See tovio behavioral.

Capability token — A signed certificate granting an agent specific operations on specific paths for a bounded time. Issued by tovio agent new.

Lease — An optional, time-bounded advisory hold a session places on a path scope; a conflicting writer gets a stronger warning (soft block only if repo policy requires). A coordination hint, not a cryptographic control.

Path scope — The glob set a capability token authorizes; reads / writes outside it are rejected before any policy evaluation (TVO-TOKEN-001).

Provenance — Structured metadata recorded on every agent commit: model hash, task ID, prompt hash, tool-manifest hash, authorizing identity, capability token ID.

Sub-token / delegation — A capability token issued by another token, with equal-or-narrower scope (monotonic restriction), for hierarchical multi-agent orchestration.

Sync & collaboration¶

Bridge mode — Bidirectional interop with a Git remote during migration: TOVIO commits ↔ Git commits.

CRDT — Conflict-free Replicated Data Type; a structure whose concurrent updates merge deterministically. TOVIO uses a CRDT (an HLC-keyed Last-Writer-Wins register) for mutable lane refs — the mechanism that propagates a lane pointer between replicas. It governs the pointer only, never the content: a divergent sync reconciles the lane into a two-parent merge-or-conflict commit (see On-lane reconciliation), so "diverged history" is never an error.

Forge — The optional commercial collaboration server: hosting, change review, agent dashboard, audit-log viewer, KA interface. Built on the same tovio-core engine.

HLC (Hybrid Logical Clock) — A timestamp combining physical time with a logical counter, used to order lane-ref updates causally despite clock skew and offline gaps. It governs the pointer-propagation layer only and never enters a merged content address; content ordering tie-breaks on Change ID, never the clock.

Lock — An exclusive or advisory hold on an unmergeable binary path (tovio lock), for paths a policy declares lockable. Two different gates run at land, and they raise different codes. TVO-LOCK-002 is the holder-agnostic divergence refusal: a land that finds an exclusive-lockable path edited divergently on both sides is refused, because a binary cannot merge and the later write would be lost silently. TVO-LOCK-001 is the holder-based refusal: before any ref advances, a land against a configured Forge takes the authoritative Forge lock for every exclusive-lockable path the land writes, and is refused when another principal already holds one. An unreachable Forge degrades that leg to the local advisory lock rather than hard-blocking the write. push runs no client-side holder check — one push advances every lane at once, so the client cannot compute the true written delta; authoritative push-time arbitration is a pending Forge-side gate.

Meta-change — A cross-repository change (meta:…) grouping per-repo changes to land atomically or sequenced, keyed off stable Change IDs. See tovio meta.

On-lane reconciliation — How TOVIO resolves a divergent sync on an unprotected lane: it runs the three-way merge engine over the two concurrent tips and advances the lane to a two-parent reconciliation commit — a clean merge, or one carrying first-class conflict objects. Both tips are parents, so nothing is stranded off-lane. The reconciliation commit has a deterministic, derived identity (a domain-separated digest of its merge-base, parents, and merged tree), so independent replicas that reconcile the same divergence mint the byte-identical commit and truly converge. Protected / require_review lanes are excluded — they reconcile through the proposal / land path.

Org policy — An organization-wide policy baseline every repo inherits and may tighten but not loosen (monotonic), with cross-repo audit and drift detection.

Proposal — A first-class Forge object (prop:…) linking a change to its reviewers and their decisions — the change-centric counterpart to a pull request (tovio change propose / tovio review). Approval is a pre-land gate where a protected lane requires review.

Relay — A bare TOVIO server that stores and serves objects. For a policy-protected payload it receives ciphertext, wrapped keys, and policy metadata without receiving a recipient private key merely by relaying; public objects and operational metadata have different visibility. It is a transport/storage role rather than the sole read-confidentiality boundary, and protocol authorization still applies. tovio serve is how you run one — there is no tovio relay noun (command reference).

Review — A reviewer's decision on a proposal (tovio review --approve / --request-changes), recorded on the proposal and gating a land where required.

Sparse / partial transfer — Syncing only the objects a peer lacks (and optionally only under declared paths), rather than the whole graph.

Webhook / event — The Forge emits events (change.proposed / landed, conflict.created, agent.scope_exceeded, lock.) and delivers them to HMAC-signed webhooks* (HTTPS); payloads carry identifiers, never plaintext or keys.

Experience & conventions¶

ADR — Architecture Decision Record. A single binding decision with context and consequences.

Delight moment — A deliberately engineered positive beat in the human experience (first commit, first land, a stored-conflict "your work keeps moving"). Human-TTY-only; never present in --json / --quiet output.

Fearlessness — TOVIO's designed default feeling: supported local mutations are recorded and reversible, Change IDs survive rewrites, and conflicts are stored rather than thrown. This guarantee does not include irreversible maintenance, expired op-log history, or remote/external side effects.

Interaction tier — Everyday / Team / Advanced; the progressive-disclosure level that governs whether a command shows in default tovio help. Distinct from the permission tier.

REQ-ID — A stable requirement identifier (REQ-STORE-001, REQ-AGENT-005…) that code and tests cite.

RFC 2119 keywords — MUST / SHOULD / MAY etc.; normative in the specifications.

Tier (permission tier) — Tier 0 Solo / Tier 1 Team / Tier 2 Enterprise; the cryptographic ambition level of a repository. Distinct from the interaction tiers used for progressive CLI disclosure.