Permissions
🚧
Tensormorph does not define its own access-control or permission model as of this writing - there is no confirmed org/repository role system to document. This page covers the access-control boundaries that already exist, outside Tensormorph itself, at the systems it touches.
Where access is actually controlled today
Tensormorph doesn't gate what you can open or do - the systems it reads from and anchors to already have their own access control, and Tensormorph inherits it rather than layering a second system on top:
- Local files - ordinary filesystem permissions on whatever's on disk.
- Hugging Face Hub - the Hub's own visibility, gating, and organization roles govern whether you can open a given model reference at all; see Hugging Face Models. A private or gated repository you don't have access to fails to open the same way it would fail to
git clone, for the same underlying reason. - Lob - since Lob is a separate, external system (see Versions and Branches), whatever access control Lob applies to commits, proposals, and history is Lob's to define and enforce, not Tensormorph's.
Reading vs. editing, locally
The one access distinction that is squarely Tensormorph's own is local and simple: opening a checkpoint for inspection never writes to it. Any operation that would produce new weights - morphing, materializing, exporting - always writes a new file or a new Lob commit rather than modifying the source you opened in place.
Related resources
- Model Repositories - where a repository-level permission model would apply, if Tensormorph defines one.
- Hugging Face Models - the access control that already governs Hub-hosted checkpoints today.
- Versions and Branches - Lob as the system responsible for history-level access control.