§ Platform / Model View
Crack the model open.
Model View is a full-screen editor for a model's internals — layers, connections, groups, weights, adapters, and the whole training setup in one place. Double-click a model node and it unfolds into three views of one definition: a canvas you rewire, a form you tune, and code you can read and diff.
Design visually, read it back as code
Sketch the architecture on the canvas, tune it field by field in the form, or write it out as code — a compact, readable model language you can review, diff, and send to a colleague. The three never disagree, because they are three views of one definition, not three copies: change a layer anywhere and the other two re-render from the same data in under 16 ms. Mistype a layer name in code, and the parser suggests the one you meant.
The synchronization is honest about what it can and cannot carry. Code holds the model's meaning — its architecture and its training semantics — while the canvas holds its layout. A layout is not something text can express, so after a code edit the canvas lays the model out again rather than pretending the text remembered where each box sat. Everything that decides what the model *is* survives the round trip; the arrangement on screen is re-derived, and the page says so instead of letting you discover it.
Any architecture you can draw
| Family | Expressed in Model View as |
|---|---|
| MLP · CNN · ResNet · Transformer | The base vocabulary — layers, edges, groups; ready as templates you unfold and edit. |
| GAN | Two networks plus the adversarial training mode — the alternation is configured, not hand-coded. |
| Siamese | A weight-sharing group: the twinned layers hold one set of weights and take one optimizer step. |
| MoE | Expert groups behind a routing layer; shapes that depend on the data carry a declared worst case. |
| RNN · LSTM · GRU | A loop over the time axis — control flow the compiler understands, not an engine special case. |
| GNN | Message passing, expressed as gather- and scatter-shaped layers over node and edge data. |
| Multi-Task | Several heads, a multi-objective training mode, and a loss combiner you pick from the catalog. |
Built-in families, not a ceiling — Encoder-Decoder, VAE, and Diffusion come along too, and anything expressible over the same structures is in scope. What the built-in set misses, you build.
Supported architectures are a criterion, not a list: Model View expresses anything you can state as layers, edges, groups, and plugs, plus a training mode. The families that come with it cover the canon — and each one is ordinary structure, never a special case wired into the engine. A GAN is two networks plus an adversarial training mode; a Siamese network is a weight-sharing group; a recurrent net is a loop over the time axis.
You rarely start from a blank canvas: the built-in templates unfold into editable models, and describing what you want in a sentence gives you a first draft. That generator is the one edit that calls a language model — and its output lands as ordinary edits, so undo, replay, and history never call the model again. A family the built-in set misses is built as content, never a gap in the engine.
Fine-tune like you mean it
Open a trained model, freeze what you trust, adapt what you don't. Freezing works layer by layer or group by group; adapters attach where you want them, picked from the catalog rather than forked into your training script. Layers can share one set of weights and take a single optimizer step between them, and learning-rate groups let the head move at a different pace from the base — which is how a few million parameters do the work of a hundred and twenty-eight.
None of this is reserved for models born here. A checkpoint that arrives as safetensors or ONNX through data & connectors opens on the same surface, and the same surgery drives its fine-tuning. As you edit, the parameter and memory numbers move with the model — total, trainable, frozen, and the footprint you are heading for — and the training planner turns that estimate into a hard check before the first step runs.
A compiler reads over your shoulder
| What it catches | When | One-click fix |
|---|---|---|
| Two layers whose shapes disagree | as you wire them | Change the layer's setting, or reroute the connection. |
| A loop that could never execute | as you close it | Remove the closing edge. |
| A trainer configured with no loss reaching an output | before the run | Connect a loss. |
| Number formats that disagree across a connection | as you wire them | Change the setting at either end. |
| Everything downstream of one real mistake | immediately | Fix the origin; the rest clears itself. |
The diagnostics are content, not a hardcoded list — a layer type someone else built ships its own checks and its own fixes through the same path.
Every edit re-checks the model incrementally — only the layers you changed and what sits downstream of them, which is how the check stays under 100 ms on a real model. A batch size that varies is understood rather than flagged; mismatched shapes, dangling connections, loops, and a trainer with no loss all surface pinned to the exact layer and port they came from. And when one real mistake ripples, the origin stays red while everything downstream turns amber — you fix one thing, not thirty.
Each diagnostic carries its fix: remove the closing edge, wire the missing connection, correct the setting — one click, applied through the same path you edit with, so a fix is undoable like any other change. The codes and the fixes are content, not a hardcoded list: a layer type someone else built brings its own diagnostics and its own fixes with it, and a type nobody has seen before renders plainly — never a crash.
The whole training setup, in one place
Everything that shapes a training run is configured where the model lives: optimizer, schedule, losses wired to outputs, epochs, batch size, mixed precision, gradient clipping, metrics — one place, never settings scattered across the app. Every picker is fed by the catalog: the optimizer list is whatever your catalog holds — the built-in breadth is on training — and a method you wrote yourself appears in the same picker as the ones that came with the product.
Two settings deserve their own sentence. The training mode is open — standard, adversarial, multi-objective, or one you define — and how exactly the run must reproduce is declared here, per run: debug, prod, or fast, visible and never silently chosen for you. Because the setup is part of the model, it stays with it: share the model, and its training setup arrives intact — the person on the other end presses run, as the training guide walks through.
Even training across many sites is set up here
When a model is trained by a group of devices rather than one, the recipe still lives in Model View. A federation section on the trainer holds the strategy for combining what each device learned, the rules for who may take part, and the privacy controls: gradient clipping and noise, with a live (ε, δ) privacy budget you can watch. For any pool beyond your own devices, differential privacy with a tracked budget and clipping is the always-on minimum, not an optional extra; and secure aggregation is checked against the size and churn of the group up front, refusing with a reason rather than pretending.
The recipe is cleanly separated from where it runs. Architecture, training setup, and federation strategy live on the model and travel with it; which group of devices actually runs it — under which trust regime, with which peers, on what schedule — belongs to the pool that executes it. The science stays portable while each deployment stays local to the people doing it.
Every gesture is also a command
Every action in Model View has a command behind it — add a layer, connect two ports, freeze a group, set the schedule — one command per action. The Copilot uses exactly those: ask it to restructure the decoder and it applies the same checked edits you would click, attributed, asked-for first, and undoable one by one. The same commands are the open interface, so a script is never a second-class citizen here.
History is scoped the way you think. Model View keeps its own undo stack while you are inside it, and on the way out the whole session folds into a single entry in the workflow's history — one model edit, however many gestures it took. Saving is versioned like everything else: a published model never changes in place — your save mints the next version, and existing versions stay exactly as they were, so anything pinned to them keeps meaning what it meant.