miStudio Roadmap: Where the Suite Is Going

First published on 2026-09-05 as “miStudio + miLLM: Direction of the Mechanistic AI Suite”. Updated on 2026-10-21 for the four-application suite, with what has shipped since, and with the plan for image models and image datasets. Each part of the plan is marked Delivered, Partly delivered, Being built or Planned. Nothing about images exists in the code yet. In November 2026 the names changed: the suite, formerly miSuite, is now miStudio; the workbench formerly called miStudio is miWorkbench; miLLM is miServer.

Where the Suite Is Going

miStudio is four applications: miDataworks makes the data, miWorkbench looks inside models and trains detectors, miServer serves models while steering and monitoring them, and miForge makes the weights. In September the roadmap described two of them. The other two have since been built, and they change the shape of the plan: the suite now covers the whole life of a question about a model, from the dataset that poses it to the weights that change in response.

The research progression is unchanged:

observing internal state
        ↓
discovering representations
        ↓
understanding their structure
        ↓
manipulating them experimentally
        ↓
discovering how they interact
        ↓
identifying candidate mechanisms
        ↓
testing those mechanisms causally
        ↓
validating and reproducing the findings
        ↓
applying validated knowledge during inference

So is the underlying question. It is not simply what feature activates here? It is:

What internal variables has this learned system developed, how are those variables represented, how do they interact, and which of those interactions actually contribute to the resulting behavior?

The two new applications widen both ends of that progression. miDataworks makes the stimulus a designed, versioned and checked object instead of whatever file was at hand. miForge makes the model itself a variable: a finding can now be tested by changing the weights and measuring again, not only by steering activations at inference time.

The Suite Today

miDataworks: the data plane (new since September)

The September roadmap proposed a “Dataset Studio” inside miWorkbench. It became its own application instead, because data work has its own lifecycle and its own failure modes.

miDataworks imports from Hugging Face or uploaded files, pinned to an exact revision. It curates through recipes of explained, previewable operator steps, labels with a classifier or a judge model behind any OpenAI-compatible endpoint, and publishes immutable versions identified by the hash of their recipe. Before a dataset becomes a detector set, it checks for the ways a detector fools its builder: shortcut columns, near-duplicates crossing splits, labels the wording alone gives away, and how far a plain text baseline gets with no model at all. It sends detector sets to miWorkbench and training sets to miForge as midataworks.dataset-version/v1 documents.

miForge: the weights (new since September)

miForge creates a model from an architecture description, changes an existing model’s weights toward a domain, or trains a low-rank adaptation (LoRA) adapter beside it. All three go through one loop: train, test against a domain set and a retention floor, checkpoint, repeat. Every checkpoint is a standard Hugging Face directory with a manifest and lineage, so any inference server can load it. It needs no other application to run. Optionally, it can update the weights miServer is serving in place, with miServer pausing serving only for the moment of each write.

miWorkbench

The sparse-autoencoder (SAE) steering environment the September roadmap described is still there: sweep one feature across strengths against the same prompt, compare features side by side, or blend several. What has been added since:

• Circuits graded by an evidence ladder. Cross-layer circuits are mined statistically, checked with gradient attribution, validated by intervention against a matched null, and tested for faithfulness. Each edge and circuit carries a rung from 0 to 3, and the word “causal” never appears below rung 2.
• Feature clusters. Related features are grouped, scored for cohesion, and steered together.
• J-Lens, fitted and validated. The Jacobian lens is fitted per model and must pass a validation gate before use. J-space interventions have shipped: additive steering along a direction, projective ablation that removes a direction’s component, and the coordinate swap the September roadmap listed as “under development”. Every intervention runs beside a size-matched random control. A mediation clamp holds chosen coordinates at their clean values to test whether an effect routes through them.
• Probe monitors with honest evidence. Small linear readouts trained on activations, with thresholds set from known negatives, confidence intervals, and their own rung ladder that ends at compared with a judge.
• A judge-prompt library. Versioned judge prompts, immutable once used and tagged with the behavior they judge. A new behavior needs a prompt, not code.
• Labeling coverage. Every labeling attempt’s outcome is recorded apart from the label, so failures can no longer pass as finished work.

miServer

miServer is still the instrumented runtime, and it now does much more of what September’s roadmap asked of it:

• Serves validated artifacts. Clusters and circuits from miWorkbench steer under one dial each. A circuit below rung 2 is refused unless someone records that they accept the risk.
• Probe monitors on live traffic. A probe is armed only after four gates pass: it fits the model’s probe budget, it was built for exactly the loaded model, miServer reproduces miWorkbench’s recorded scores, and its evidence is recorded. A verdict is recorded and shown. It does not block or rewrite a generation.
• Sessions. The requests of one conversation are grouped, and each verdict records its turn. Recording conversation text is opt-in, off by default and kept for seven days.
• Per-model probe limits measured on hardware. miServer times each model’s own step and each probe’s cost on the card it runs on, and admits probes against a time budget.
• Scoring, batches and leases. Next-token log-probabilities in float32 when precision matters, a durable batch application programming interface (API), and model leases so a long job is not swapped out from under.

The GGUF boundary from September still holds. GGUF models (the llama.cpp quantized format) are served, not instrumented. llama.cpp exposes no hook points, so SAE steering and probes stay on the Hugging Face path. A GGUF model can be the judge or the workhorse; it cannot yet be the subject.

What Shipped From the September Roadmap

Human Interfaces and Programmatic Interfaces

Automation should not come at the expense of interactive research. A researcher often learns something because an unexpected activation pattern or response transition becomes visually obvious. Every application therefore keeps a full interface, and every capability is also reachable programmatically.

The September design showed one shared MCP server. The suite now runs one per application: miWorkbench’s carries about 280 tools, including the families that drive miServer and reach into miDataworks; miDataworks’ about 190; miForge’s 90. The shift that mattered was not the count but the approval model. An agent can read, plan, validate and dry-run anything. Actions with consequences wait for a person: starting work on a graphics processing unit (GPU), publishing to the Hugging Face Hub, changing settings or keys, evicting a served model, and deleting things. An agent cannot approve its own request.

               Human Researchers / Operator
          /           |             |          \
         ▼            ▼             ▼           ▼
    miDataworks  miWorkbench    miServer     miForge      (full interfaces)
         │            │             │           │
         ▼            ▼             ▼           ▼
          APIs · portable documents · approvals
         ▲            ▲                         ▲
         │            │                         │
        MCP          MCP (+ miServer family)   MCP
         ▲            ▲                         ▲
          \           |                        /
               Agents / Research Harnesses

The personal-data detector example on the miStudio page shows this working end to end, including the twelve places the agent found the MCP servers were not enough, and what changed because of them.

A Common Scientific Model

The suite is organized around a simple model of research:

Stimulus / Observation
        ↓
Internal Representation
        ↓
Representation Interaction
        ↓
Mechanism
        ↓
Prediction / Action / Output

For each stage, the suite should help answer a stronger sequence of questions: Can we observe it? Can we decode it? How is it represented (a sparse feature, several features, a J-space coordinate, a direction, a subspace, a population code, a spatial or temporal state)? Where and when does it appear? What does it interact with? Can we manipulate it, and does the effect behave predictably with dose? Does it survive changes of context? Can it be reproduced?

Two questions are new since September, because the suite can now change the data and the weights:

• Does it depend on the data? Does the same representation appear when the stimulus distribution changes? miDataworks makes the distribution a recorded, reproducible object, so the question can be asked with a controlled change.
• Does it depend on training? Does the representation emerge, move or vanish when the weights change? miForge writes every checkpoint with its lineage, so a representation can be followed across a training run rather than studied only in a finished model.

From Features to Representation Systems

An SAE feature is one possible representation object, not the universal unit of interpretability. The suite already holds several kinds side by side:

Model Internal State
        │
        ├── Native Activation Space
        ├── SAE Feature Space          (delivered)
        ├── Feature Clusters           (delivered)
        ├── Circuits across layers     (delivered)
        ├── Jacobian Lens / J-space    (delivered)
        ├── Probe Directions           (delivered)
        ├── Learned Subspaces          (planned)
        ├── Population Codes           (planned)
        └── Future Representation Methods

The next step is to relate them. If an SAE feature, a probe direction and a J-space coordinate each expose related information, the suite should be able to say so, and use their agreement or disagreement as evidence. The system should follow the representation rather than require it to fit the tool.

From Steering to General Intervention Experiments

The September roadmap described the generalized experiment:

Stimulus
  ×
Representation System
  ×
Representation Object(s)
  ×
Intervention
  ×
Intervention Magnitude
  ×
Context

Much of it now exists. SAE steering, cluster and circuit steering, J-space additive steering, projective ablation and coordinate swap are delivered, and circuit validation already intervenes against a matched null. Every J-space intervention carries a control that can be reconstructed from its seed, and a run too small to separate from its control says so instead of reporting a result.

Planned: activation patching between prompts, clamping and replacement for SAE features, subspace projection and removal, and one experiment record that spans every intervention kind, so that a dose-response sweep on an SAE feature and one on a J-space direction can be compared directly.

Evidence, Not Just Interpretations

An automatically labeled representation is not equivalent to one whose role has survived controlled interventions across contexts. The suite now enforces that distinction in two ladders.

Circuits: mined → attribution-supported → causally validated → faithfulness-tested.

Probes: trained → detects on held-out data from the same distribution → detects on unseen tasks → detects on unseen tasks, compared with a judge.

Both are computed from what actually ran, worded by the server so no screen can overstate them, and kept as history when a test fails. The September progression had more steps (dose-response, context validation, replication). Those remain the direction: each should become a recorded rung with a test that earns it, not a label someone applies.

Dataset Engineering as Experimental Design

This section of the September roadmap is now an application. miDataworks’ recipes, versions and checks are what made the personal-data detector’s numbers believable: the leakage check refused the first detector set for 189 near-duplicate pairs across splits, and the shortcut audit showed that bag-of-words already reached 0.952, which is the bar a probe has to beat to mean anything.

Planned: controlled mixtures as a first-class experiment. The same campaign should run against two stimulus distributions and report whether a representation’s location, geometry or strength changed, with both datasets’ recipes in the record.

Workflow and Research Campaigns

A workflow executes an experiment. A campaign executes a family of them:

3 datasets
×
4 layers
×
2 representation methods
×
5 intervention strengths
×
3 random seeds

Today an agent can run such a campaign over MCP, with each GPU step waiting for approval. What is missing is the campaign as a recorded object: expanded, scheduled, resumable, aggregated and viewable as one thing. Planned, and now spanning all four applications, since a campaign may need to build a dataset, train probes, and fine-tune a model before measuring again.

Representation Geometry and Emergence

A concept may need a 20-dimensional subspace rather than one interpretable direction. That is information about how the model represents it, not a failure of interpretability. Planned analyses: principal component analysis (PCA), singular value decomposition (SVD), canonical correlation analysis (CCA), intrinsic dimensionality, representational similarity, and comparison across layers and models.

Emergence is where miForge changes the plan. September’s roadmap asked how representations form, but the suite could only look at finished models. miForge’s checkpoints, each with lineage and test scores, make it possible to capture the same stimuli at every checkpoint of a run and see where a representation appears, sharpens or disappears. Planned: emergence analysis across miForge checkpoints, starting with probe accessibility per layer per checkpoint, which uses machinery that already exists.

From Representation Discovery to Mechanism Discovery

Finding a representation does not establish how it participates in computation. Circuit discovery is the delivered first step: mined edges, attribution, intervention against a null, and faithfulness. Planned: candidate mechanisms that mix kinds of object (an SAE feature group feeding a J-space direction feeding a later feature), mediation analysis across them, and tests of whether a mechanism persists across contexts, datasets and checkpoints.

Research-to-Runtime Integration

The intervention artifact September described now exists as three portable documents: circuit, cluster and probe definitions. Each names its model and revision, carries its evidence, and is resolved by miServer independently, from a file or from Hugging Face. A probe definition carries test vectors, so miServer proves it scores identically before trusting a verdict.

miForge adds a second path to runtime. A finding can become a change in the weights, through fine-tuning or an adapter, tested against a retention floor, and loaded into miServer or written into the served weights in place.

White-Box Evaluation and Conditional Control

Probe monitors are the first delivered form of white-box evaluation: an internal signal, validated in miWorkbench, applied to every request in miServer. They are deliberately evidence and not gates. A verdict does not stop, reroute or rewrite a generation, because a threshold has to prove itself on real traffic first.

Being built: a behavior catalogue in miWorkbench tying each behavior’s definition, data, probes, judge prompts and operating point together, and judge spot-checks that sample live sessions and report how often probe and judge agree, with a confidence interval.

Planned, after that evidence exists: assertions that an expected representation is present or a known failure signature is absent, and conditional control:

WHEN internal state X is present
AND context Y applies

THEN
  apply intervention Z

UNTIL condition Q

Runtime Evidence Should Return to Research

Real traffic exposes contexts missing from the research data, unexpected combinations, side effects and drift. Sessions in miServer and judge spot-checks in miWorkbench are the first part of the return path (being built). miDataworks completes it: disagreements between probe and judge are exactly the rows worth reviewing by hand, labeling, and folding into the next version of the detector set. Planned: that loop as a supported workflow, from flagged live session to new dataset version to retrained probe.

     miDataworks ──► miWorkbench ──► miServer
          ▲                             │
          └────── flagged sessions ◄────┘

Image Models and Image Datasets

Images are the suite’s next modality, ahead of video and audio. The reason is practical: the open models people run locally increasingly take images, and much of the content worth monitoring arrives as images. A screenshot of a form, a scanned document or a photographed whiteboard can carry the same personal data a text detector catches, and a text-only detector never sees it.

Adding images is not one feature. It touches every application and every portable document, and it brings data problems text does not have. This section says what it implies, in the order the work should happen. None of it is built yet.

Which image models, in which order

1. Vision-language models (VLMs) first: an image encoder, a projector, and a language model that answers in text (Liu et al., 2023). The language half is exactly what the suite already instruments, the OpenAI chat API already has a shape for image input, and the output is text, so judges, probes and the evidence ladders carry over.
2. Image encoders on their own: vision transformers (Dosovitskiy et al., 2020) and contrastively trained image-text encoders such as Contrastive Language-Image Pre-training (CLIP; Radford et al., 2021), which are also the encoders inside most VLMs.
3. Text-to-image diffusion models later (Rombach et al., 2021). They have no next token, run many denoising steps, and need a different runtime, so they come after the other two.

What changes in the scientific model

Representations have to be located in more than token positions. The September roadmap’s generalized Activation Context becomes concrete:

Activation Context
   ├── token span            (text, today)
   ├── image patch           (one cell of the encoder's patch grid)
   ├── image region          (a set of patches, a box or a mask)
   ├── global image token    (the encoder's summary token, where it has one)
   ├── image tokens in the language model
   │                         (the projected patches, after the projector)
   └── multimodal alignment  (which text tokens attend to which patches)

A visual variable can then be followed through the whole path:

Image ─► Encoder layers ─► Projector ─► Language model layers ─► Response

There is published ground to build on. Network dissection measured units in vision models against labeled concepts (Bau et al., 2017). Concept activation vectors are the image-model ancestor of the suite’s probes (Kim et al., 2017). CLIP’s image representation has been decomposed into text-describable parts of individual attention heads (Gandelsman et al., 2023). SAEs have been trained on vision models (Gorton, 2024), on vision-language models (Pach et al., 2025), per image patch to study what changes during adaptation (Lim et al., 2024), across several vision models at once (Thasarathan et al., 2025), and on diffusion models (Surkov et al., 2024). Logit-lens-style readouts of image tokens inside VLMs have been studied directly (Neo et al., 2024), and an open toolkit for vision and video interpretability exists (Joseph et al., 2025). The suite’s contribution is not new methods. It is the same discipline it applies to text: recorded runs, honest baselines, evidence ladders and a path to runtime.

miDataworks: image datasets

Image data needs everything text data needs, plus problems text does not have.

• Sources and storage. Image datasets from Hugging Face and uploaded folders. Images stored by content hash, so a version can be rebuilt and checked byte for byte, with the decoded size, format and color mode recorded per row.
• Licensing and provenance per image. Image collections often mix licenses row by row, and many large web-scraped collections carry little provenance at all. Each row should carry its own license and source, and a version should refuse to publish rows with none.
• Screening before storage. Large web-scraped image-text collections have been shown to contain explicit, violent and stereotyping material (Birhane et al., 2021). Screening for illegal and unwanted content has to happen before anything is stored, not as a later filter. The suite should refuse unscreened bulk web-scrape imports rather than ingest first and clean later.
• Privacy inside the pixels. Faces, license plates, addresses and document text are personal data even when no column says so. Embedded metadata, Exchangeable Image File Format (EXIF) data included, can carry location and device. Metadata is stripped on import by default, and personal content in images is flagged for review.
• Leakage checks that see images. Two crops, resizes or recompressions of the same photo are the image version of a near-duplicate. Perceptual hashing and embedding similarity replace text n-grams for finding pairs that cross splits.
• Shortcut audits that see images. The image analogue of “text length alone scores 0.505” is a baseline on resolution, aspect ratio, file format, compression quality, color statistics or a watermark. If any of those predicts the label, the detector will learn it. A simple baseline on these properties, and a linear probe on a generic frozen encoder, become the bars a probe must beat.
• Labeling with VLM judges and people. Judges that see the image, rubrics that say what to look at, and a human review queue that displays images with the label in question.
• Out-of-distribution means unseen kinds of image. For images, the held-back test set should be a different source or style: screenshots against photographs, scans against renders, another country’s documents.
• A new contract version. midataworks.dataset-version/v1 describes text rows. Image rows need a new version of the contract, not a silent extension, published by miDataworks and vendored byte-identical by miWorkbench and miForge with their tests pinning it.

miWorkbench: looking inside image models

• Loading and capture. Load VLMs and encoders through Hugging Face Transformers with their processors, and capture activations per patch in the encoder and per image token in the language model. A single image becomes hundreds to a few thousand tokens depending on the model’s processor, so capture storage and memory have to be measured per model, not assumed.
• SAEs on images. Train SAEs on encoder layers and on the language model’s image-token positions, with the existing architectures.
• A feature viewer that shows pictures. The text viewer highlights tokens. The image viewer has to show each feature’s top-activating images with a heatmap over the patches that fired, and crop to the region that matters.
• Labeling image features with a VLM judge shown those crops, with the same outcome recording and coverage strip as text labeling.
• Circuits across the projector. Edges from encoder features to language-model features are the visual version of a cross-layer circuit, and the most interesting place to look for how visual information becomes language.
• J-Lens on image tokens. Projecting image-token residuals through the language model’s output layer shows what the model is poised to say about each patch.
• Probes on images. “This image contains personal data”, “this screenshot shows credentials” or “this document is a medical record” become probes trained, thresholded and laddered like their text counterparts, against image-native baselines and an image-reading judge.
• Steering from image features. Adding image-derived feature directions while the model describes an image, with the same sweeps and controls.

miServer: serving and monitoring image requests

• Image input on the OpenAI API. Accept image content parts in chat requests, preprocess them with the model’s own processor, and record which processor configuration ran. Images inline as data URIs by default. Fetching remote image URLs makes the server request addresses a client chose, which is a server-side request forgery (SSRF) risk, so it stays off unless an operator turns it on with an allowlist.
• Probes on image-bearing requests, with the same four gates. Parity test vectors have to include images, so miServer proves it preprocesses and scores identically to miWorkbench.
• Sessions treat images as more sensitive than text. Recording image content is separately opt-in, with its own retention, and never broadcast.
• Probe limits include the encoder. The measured cost per request has to include encoding the image, which can exceed the cost of the text.
• The GGUF boundary holds. llama.cpp can serve some VLMs with a separate projector file. They will be served, not instrumented, for the same reason as text GGUF models.
• Image generation endpoints only arrive with diffusion models, at the last stage.

miForge: training with images

• VLM fine-tuning and adapters, starting with LoRA on the language half while the encoder stays frozen, which is the cheapest and best-understood path.
• Test and retention sets with images, so a domain adapter is checked for what it gains and what it forgets, as it is for text.
• Checkpoints record their processor, because a VLM checkpoint is only reproducible with the image preprocessing it was trained with. The checkpoint and adapter manifests gain the fields to say so.
• Diffusion adapters (Gandikota et al., 2023 shows concept-specific LoRA adapters for diffusion models) belong to the last stage, with diffusion serving.

Hardware and cost

Everything in the suite already pins work to a card by its identifier and spreads across however many cards a machine has. Images raise the stakes: an encoder plus a language model needs more memory than the language model alone, images multiply sequence length, and patch-level activation capture multiplies storage. Every image capability should report its measured memory, time and storage on the card it ran on, the same way miServer measures probe limits, rather than quote figures from elsewhere.

Order of work

1. Image data foundation. miDataworks image sources, per-row license and provenance, screening before storage, metadata stripping, perceptual-hash leakage checks, image shortcut baselines, VLM labeling with an image review queue, and the new dataset-version contract.
2. Serve VLMs. miServer accepts image input, served and scored, with processor recording, before any instrumentation.
3. Look inside VLMs. miWorkbench capture per patch and image token, SAEs on encoder and language layers, the image feature viewer, and image feature labeling.
4. Probes on images, live. Image probes trained in miWorkbench against image-native baselines and an image-reading judge, armed in miServer with image parity vectors. A personal-data-in-images detector is the natural first worked example, extending the text one.
5. Encoders and training. Standalone image encoders in miWorkbench; VLM adapters with image test and retention sets in miForge.
6. Diffusion. SAEs and steering on diffusion models, diffusion adapters in miForge, and image generation in miServer.

Video and audio follow, reusing the generalized Activation Context: a frame range or a time-frequency region is one more kind of location to attach a representation to.

Capability Horizons

The roadmap is a sequence of capability horizons rather than releases.

Long-Term Direction

The suite is moving toward seven connected functions: discover internal variables by several methods; experiment on them individually and together; understand what they encode and where they emerge; relate them into mechanisms; validate by controlled intervention and replication; operationalize what survives as portable artifacts or changed weights; and observe and control at runtime, with a path back into research.

The questions stay the same, now across text and images, and across data, activations and weights:

What internal variables does the system develop?

How are they represented, and how do they change across layers, training, data, models and modalities?

Which of their interactions actually contribute to behavior?

Can those mechanisms be manipulated predictably, and can validated knowledge stay useful during real inference?

The architecture still assumes nothing about what form the important internal variable will take: an SAE feature, a J-space coordinate, a direction, a subspace, a population code, an image region or a temporal state. The suite should follow the internal structure wherever the learned system actually puts it.