Announcing Tensormorph 2.0

Tensormorph 1.0 gave open-weight models one navigable address space - a Semantic Model Graph running from a whole checkpoint down to a single scalar, with every view a synchronized projection of the same selection. It answered what is this, where does it sit, and how does it compare. It deliberately stopped short of answering what happens if I change it and what does it actually do when it runs - those were confirmed directions, not shipped ones.

Tensormorph 2.0 answers both, without touching any of the contracts 1.0 asked you to build on. The Semantic Model Graph, the InspectionContext, the address grid, view synchronization, the tile/LOD pyramid, the tm-plugin/1 ABI, and the .tmproj project format are exactly as stable today as they were in 1.0 - see Stability in 2.0. What's new sits on top of them: a non-destructive edit substrate that shares its machinery with Morph rather than duplicating it, a runtime substrate that joins live activations and KV state into the same address space as static weights, and a collaboration substrate that takes Lob-side review from "the content is supported" to "there's a UI for it."

From inspection to intervention

1.0's daily workflow ended at "here's exactly what's different, and here's the exact scalar." Acting on that finding meant leaving Tensormorph - editing a weight in a script, pushing a change through review by email or a diff of raw files, or wiring up a separate profiler to see how a suspicious tensor actually behaves at runtime. Each of those tools has its own selection model, its own addressing, its own notion of "the thing I was just looking at."

2.0's organizing idea is that intervention shouldn't require a second address space. An edit is a TensorOperation producing a TensorDelta, addressed exactly like everything else in the Semantic Model Graph - which is also, unchanged since 1.0, what a Morph expression already was. A runtime trace is a set of tensors joined into the same graph by node, time, token, step, and rank, rather than a parallel timeline you cross-reference by hand. A Lob-side review is a comparison pair with a status attached, not a different kind of object.

What's new in Tensormorph 2.0

Non-destructive Tensor Edit

Tensormorph 1.0 scoped every weight-mutating tool to the Morph view specifically, so nothing done while exploring the Architecture or Tensor Volume views could accidentally alter a weight. That boundary hasn't moved in 2.0 - what's new is a dedicated Tensor Edit workspace built on the same non-destructive machinery Morph already used, applied at finer granularity than whole-model composition.

An edit is authored as a TensorOperation - scalar edit, row/column edit, zero, fill, scale, add, clamp, normalize, mask, copy/paste between compatible regions, replace from another checkpoint, interpolate, noise, or a quantize preview - and operations accumulate on a Transform Stack: reorderable, individually enabled or disabled, re-parameterizable after creation, the same modifier-style workflow 1.0's own Morph DAG already used internally. Nothing on the stack touches the original .safetensors bytes; every operation is recorded as a TensorDelta overlaid on top of the source tensor, exactly like a Morph node.

Because Edit and Morph now share TensorOperation/TensorDelta as one substrate, an edit stack scoped to a tensor or a region is a Morph expression - just a smaller one, and one you can promote into a full morph DAG if a change you made interactively turns out to be worth reusing across checkpoints. Both paths end the same way: Preview renders the delta before anything is written, Validate checks shape, dtype, semantic compatibility, NaN/Inf, and a VRAM/RAM and I/O cost estimate, and Apply/Bake materializes a new checkpoint with recipe.json recorded alongside it - never a mutation of the original file.

Undo and redo operate at the level of individual stack operations, a session can hold named snapshots for quick before/after comparison, and reverting a selection change is tracked separately from reverting a value change, so undoing "I clicked the wrong tensor" never also undoes an edit you meant to keep.

Tensor Cursor and gizmo interaction

A persistent Tensor Cursor - the spatial-tool analogue of a 3D cursor - now carries a tensor path, logical coordinate, decoded value, containing block, and world-space position simultaneously, and snaps to a scalar, a tile boundary, a row/column/channel axis, a tensor edge, or a semantic boundary like a head or expert. It's the shared pivot for several tools at once: a navigation target, the origin the Measure tool reads from, the slice origin when you step through an axis, the comparison coordinate when two checkpoints are loaded, and the pivot an edit operation transforms around.

A small gizmo set operates on top of the cursor and the address grid: axis handles mapped to the tensor's own axes, range handles for dragging a slice boundary, plane handles for picking out a matrix plane, a threshold handle for interactive clipping, and an LOD handle for expanding or collapsing the resolution you're looking at. Every handle snaps to the address grid described in 1.0 - a handle never drifts to a boundary that doesn't correspond to a real tile, axis, or semantic edge.

Runtime activation and KV-state inspection

RuntimeProbe - an experimental trait in 1.0 - is a stable, documented extension point in 2.0, and Tensormorph ships framework adapters that use it out of the box. A captured or live run joins activations, gradients, attention and routing weights, and KV-cache occupancy into the same Semantic Model Graph as the static weights that produced them, addressed by node plus time, token, step, and rank. The Runtime Flow 3D view, present but preview-only in 1.0, is where this shows up spatially: the same perpendicular-planes MatMul convention from 1.0 now traces a live tensor's actual values through the graph, not just the static shapes.

A runtime cursor scrubs or steps through token, time, step, or rank, and the deterministic Play/Pause/Step controls 1.0 introduced for tracing a single MatMul extend directly to stepping through a captured run. Breakpoints accept the same TQL used everywhere else in Tensormorph - a condition like an attention-entropy threshold or a routing-weight predicate, evaluated against a runtime tensor exactly the way a static filter evaluates against a stored one.

Expanded morph operation catalog

The morph operation catalog 1.0 flagged as still finalizing is stable in 2.0: task-vector addition, linear and spherical (SLERP) interpolation, and TIES/DARE-style selective merging, complete with a sign-conflict map rendered as its own overlay wherever a merged task vector disagrees with itself across contributing checkpoints. Coefficient inheritance across a DAG and mask inputs for region-scoped merges are both part of the same stable surface.

Lob review and branch-aware comparison

1.0 supported reviewing a Lob-side weight-space pull request by loading it as an ordinary comparison pair; 2.0 adds the UI that was missing. Approve and Request Changes now act directly on a loaded comparison pair, discussion threads anchor to a specific tensor address or selection rather than to the pull request as a whole, and Lob's branch and merge semantics - settled since 1.0 shipped - mean a Tensormorph project can track a moving branch, not just a single pinned commit. A tracked branch fires the same stale-note behavior a commit pin always has when the underlying history moves past what you materialized against.

Tile Server and thin web client

An optional Tile Server component serves precomputed tile statistics and LOD pyramids over a network, so a lightweight web client can browse a large checkpoint's structure and statistics without a full desktop session or a local copy of the weights. In 2.0 the thin client is read-only - browsing, search, statistics, and diffing two already-indexed checkpoints - while editing, morphing, and runtime capture stay desktop-only.

Public plugin registry

The direct, share-within-your-team model 1.0 shipped with is joined by a signed-publisher registry, browsable from inside Tensormorph's plugin panel. The tm-plugin/1 ABI is unchanged, so every plugin built against 1.0 continues to load without modification. WASM remains the default sandboxed path for anything distributed through the registry; the signed-native path 1.0 offered for workloads a sandbox genuinely can't support - custom CUDA kernels, for instance - stays available but isn't distributed through the registry itself, given the trust decision a native plugin requires.

Broader accelerator kernel coverage

1.0 noted that low-bit quantized-operation kernels weren't uniformly implemented across all five backends. That gap is closed in 2.0: CPU, WebGPU, CUDA, ROCm, and Metal all carry the same quantized-operation coverage. The fallback behavior is unchanged - where a backend still lacks a kernel for something new, Tensormorph falls back to a slower but correct implementation and always surfaces that explicitly, never substitutes an approximation silently. The AcceleratorBackendPlugin interface itself hasn't changed since 1.0.

High-dimensional projection strategies

The Tensor Volume view's rank-4+ handling grows past 1.0's slicing and small-multiples: a facet-grid mode holds two axes free simultaneously, and a reduction mode collapses a chosen axis by max, mean, or sum into a single view. Both are explicit, labeled operations selectable the same way slicing was in 1.0 - never an implicit flatten with a hidden axis order.

CLI stabilized

tmorph query, tmorph validate, and tmorph render move from 1.0's "shape confirmed, not frozen" status to the stable CLI surface, sharing the same TQL used in the command palette, the Console REPL, and breakpoint conditions. tmorph index is unchanged.

Stability in 2.0

Everything listed under Stability in 1.0 still holds without modification: tensor resource identity, the Model → Architecture → Layer → Module → Tensor → Tile/Block → Row/Col/Channel → Scalar hierarchy, the shared InspectionContext, the address grid, view synchronization, the tiling and LOD contract, the tm-plugin/1 extension points, and .tmproj as the durable project artifact.

2.0 adds four more:

• TensorOperation / TensorDelta - the shared substrate underneath both Edit and Morph; an edit stack and a morph DAG are the same kind of object at different scopes.
• Tensor Cursor addressing and snapping - a cursor's coordinate and snap targets are defined the same way across every view that supports it.
• Runtime-joined addresses - a RuntimeProbe tensor's address (node plus time/token/step/rank) is a documented extension of InspectionAddress, not a parallel identity scheme.
• The plugin registry's distribution contract - a registry listing points at a tm-plugin/1 package; the ABI a plugin is built against doesn't change based on where it's distributed from.

What isn't frozen: Lob's handling of genuine merge conflicts (versus straightforward review), write support in the thin web client, and the specific set of built-in high-dimensional projection strategies - all active design areas 2.0 leaves room for.

Getting started with 2.0

[UPDATE_COMMAND]
[OPEN_MODEL_COMMAND] model.safetensors

If you're coming from a 1.0 workflow, the arc is unchanged through step 5 below - steps 6 and 7 are what's new:

1. Open a local .safetensors file or a Hugging Face Hub reference, same as 1.0 - the tree still populates from the header alone.
2. Navigate in the Outliner or the Architecture view; select a tensor and read it in the Matrix and Heatmap view.
3. Load a second checkpoint with Compare With… to get a Diff view, or a Lob-side pull request to review it directly with Approve / Request Changes.
4. Switch to Tensor Edit on a selection to open the Transform Stack, add an operation, and watch the Preview overlay before deciding whether to Validate and Materialize.
5. Load a captured run, or attach to a live one through a RuntimeProbe adapter, and step through it in the Runtime Flow view with the same Play/Pause/Step controls used for a single MatMul in 1.0.
6. Browse the plugin panel's registry tab for a published ModelAdapter, RuntimeProbe, or TensorMetric plugin instead of writing one from scratch.
7. Save bookmarks, the current Transform Stack, and your layout to .tmproj, same as 1.0 - older .tmproj files from 1.0 open unchanged.

Migration from 1.0

Tensormorph 2.0 is additive over 1.0's stability contracts, so most 1.0 workflows carry over without changes:

• Tensor addressing - unchanged. The Semantic Model Graph and every address within it are exactly as stable as 1.0 promised; nothing needs re-addressing.
• .tmproj files - a 1.0 project file opens unchanged in 2.0. New fields (Transform Stack state, runtime bookmarks, Lob branch tracking) are simply absent until you save from 2.0, at which point they're added alongside what was already there.
• Derived caches - .tmidx, .tmtiles, .tmpair, and .tmrun are still regenerable caches. A tmorph index refresh picks up the additional statistics 2.0's Edit preview and runtime views use; you don't need to re-index just to open a 1.0-indexed checkpoint.
• Plugins - any tm-plugin/1 plugin from 1.0 loads unmodified; the ABI hasn't changed.
• Lob-linked checkpoints - a 1.0 project pinned to a single commit keeps working exactly as before; branch tracking is opt-in, not required.
• CLI - tmorph index is unchanged. tmorph query, validate, and render move from experimental to stable; [CONFIRM_BEFORE_PUBLISHING: list any flags on these three subcommands that changed shape between 1.0's experimental builds and 2.0's stable release.]
• Direct plugin sharing - [CONFIRM_BEFORE_PUBLISHING: does a plugin shared the pre-registry, team-local way in 1.0 need any manifest change to also appear correctly once a team opts into browsing the public registry?]

If you're opening 2.0 for the first time without a 1.0 workspace, there's nothing above to act on.

What's next

2.0 establishes the edit, runtime, and collaboration substrates; several directions build directly on them without changing the contracts above:

• A distributed index service, so a very large or organization-shared checkpoint's tile pyramid can be built and served once rather than per-workstation - the natural next step once the Tile Server exists at all.
• AI-assisted operations - natural-language transform planning and diagnosis, building on the ? natural-language-to-TQL input 1.0 already shipped in the command palette, extended to proposing a Transform Stack rather than just a selection.
• Live collaborative sessions, beyond today's asynchronous Lob review - multiple cursors, live-shared selection, in the spirit of the InspectionContext already being one shared object per session.
• Write support in the thin web client, once read-only browsing has been in the field long enough to validate the access-control model a write path needs.
• Additional RuntimeProbe framework adapters and additional ModelAdapters for architectures not yet recognized out of the box.

None of these are commitments with dates attached - they're the directions 2.0's architecture was built to support.

Thank you

Tensormorph 2.0 exists because of everyone who put 1.0 through its paces on a real checkpoint, filed the issue that became the Transform Stack's undo model, pushed on where Lob's review UI needed to actually live, or wrote a tm-plugin/1 plugin worth putting in front of other people. Thank you to our early users, to the open-source contributors who worked on the application and its documentation, to the researchers and model authors whose work this tool exists to make more legible, and to the scientific-visualization, GPU, and compiler communities whose prior work this project builds on - including [CONTRIBUTOR_NAMES] and our [CONTRIBUTOR_COUNT] contributors.

• Documentation: [https://github.com/TensorMorph/docs (opens in a new tab)]
• Repository: [https://github.com/TensorMorph/tensormorph (opens in a new tab)]
• Download: [https://github.com/TensorMorph/tensormorph/release (opens in a new tab)]
• Discussions: [https://github.com/TensorMorph/tensormorph/discussions/1 (opens in a new tab)]
• Changelog: [https://github.com/TensorMorph/tensormorph/blob/main/CHANGELOG.md (opens in a new tab)]