Versions and Branches
Tensormorph doesn't store weight history itself - that's Lob's job, as an external, separate system. What Tensormorph does is address a specific version precisely, and detect when that address has gone stale.
Commit pins and stale-notes
A checkpoint loaded through Lob carries a commit pin: a reference to the exact Lob commit and content hash it was materialized from. If Lob's history moves past that pin, Tensormorph flags a stale-note rather than silently comparing you against outdated history - the same mechanism described in Merge Conflicts.
Addressing a version
The same three-way addressing scheme used for Hugging Face Hub models - an exact commit hash, or a named, potentially-moving reference - applies to a Lob-versioned checkpoint. A commit hash is the only form guaranteed stable; anything named can move underneath you, which is exactly what a stale-note is designed to catch.
What "branch" means here, for now
A branch, in the general sense, is a named line of divergent history - but Lob's specific branch and merge semantics for weight history (as opposed to text) aren't finalized. What's confirmed today is narrower: Tensormorph can load and diff a weight-space pull request (a Lob-side reviewable proposal) against its base, and can detect when two proposals conflict - see Reviews and Merge Conflicts. Treat anything beyond that - a full branch-switching UI inside Tensormorph, for instance - as plausible future direction rather than documented behavior.
Related resources
- Merge Conflicts - the fullest picture of what's confirmed about the Lob boundary today.
- Lob CLI - where actual branch and history operations happen today, outside Tensormorph.
- Reviews - reviewing a weight-space pull request from inside Tensormorph.