Technology · Available
Primary Versioning™
A people-centric model of version control, in which the computer itself — not the user — decides which moments are worth keeping. Productized as File Journey.
Why version control needed a third model
Version control was invented as an R&D tool, yet it now sits silently at the heart of nearly every collaboration system people use every day — cloud drives, CMSs, document editors. The tools shape us, as McLuhan put it, and forty years of evolution have left us with two dominant models, both built for software engineers.
Client/server systems (CVS, Subversion) hand authority to a central repository: someone checks out a file, edits, checks in, and conflicts are resolved by picking a winner. Distributed systems (Git, Mercurial) drop the server but push the burden of reaching linearity onto every contributor through manual merges. Both require discipline, both require expertise, and both interrupt the flow of the people actually doing the work.
The problems both inherited
- Versioning is manual — tedious, and only captured at far-apart points in time.
- Collaboration forces people to wait, lock, or merge before they can move on.
- Conflicts demand a winner; the losing work is discarded.
- The mental model assumes a linear history, which rarely matches how people actually work together.
- The vocabulary (check-in, push, rebase, blame) was designed for software engineers, not for writers, designers, lawyers, or scientists.
Primary Versioning™, in principles
Principle
Simplify to the bone
Folders and files — the objects people already understand. No staging area, no working copy, no remote.
Principle
The computer decides what to keep
A pattern-detection engine listens to file-modification events from the file system and automatically captures the moments worth remembering — the user just keeps working.
Principle
Help the user remember
Versions are surfaced with human-meaningful context, not opaque hashes like ab → 5e → 19 → dc.
Principle
Reveal hidden links
The relationships between versions, files, and people are made visible instead of buried in a DAG.
Principle
Don't wait, don't lock, move on
Collaborators never block each other. Two people editing the same file both keep working — and both keep their work.
Principle
Non-linear by design
History is a graph of co-existing versions, not a single line someone has to win.
How it works
A pattern-detection engine on the file system
At the core of Primary Versioning™ is an engine that quietly watches the file system. It receives a stream of File Modification Events — saves, renames, moves — and applies pattern detection to decide which of those moments are significant enough to be preserved as a version. The user never has to commit, snapshot, or name anything.
How the three models compare
| Dimension | Client/Server | Distributed | Primary |
|---|---|---|---|
| Versioning | Manual | Manual | Automatic, pattern-detected |
| Authority | Central server | Every clone | Each user's own history |
| Conflicts | Pick a winner | Manual merge | Co-exist, non-linear |
| Collaboration | Wait / lock | Pull, merge, push | Move on, never block |
| Audience | Engineers | Engineers | Anyone who saves a file |
From one user to many
For a single user, Primary Versioning™ replaces manual snapshots with a continuous, navigable history of every save — without asking the user to learn anything new. For two or more users, it removes the wait, the lock, and the forced winner: versions branch naturally, co-exist, and can be reconciled when (and if) the people involved choose to.
The result is a versioning substrate that fits how humans actually collaborate on documents, designs, contracts, and research — not just on source code.
Product
File Journey
File Journey is the product encapsulation of Primary Versioning™, built around the single-user and same-machine collaboration scope of the underlying patent (excluding its network portion). A dedicated product page is coming soon.