Everything MatrixAI Studio does,
point by point

MatrixAI Studio finds the best predictive model for a table of data. You bring a CSV file and say which column you want to predict. Several engines compete on your data using cross-validation, a test set is kept aside and used once, and the Studio tells you which engine wins — or that none is good enough — and why, in writing. It runs on your own computer with Docker, in English and in Spanish.

What it can predict

• Binary classification: two outcomes, such as repays or defaults. Selection metric: AUROC.
• Multiclass classification: three or more classes. Selection metric: accuracy.
• Regression: a number. Selection metric: RMSE.
• One free-text column (Spanish or English) per study, which competes with a text-only candidate. Dates are used as parts: year, month, weekday and days elapsed.

The parts of the Studio

• The study (the default path): framing, progress, results and use. Sections 2 to 5.
• The lab (expert mode): design your own network, train it and look inside. It is for learning and experimenting, not the route to the best model of your data. Section 6.
• “Does it work here?”: check, on your own cases, whether a risk score you already use works. It trains nothing. Section 7.
• Saved (under “Your library”): the studies and the checks you kept. Section 8.

The home screen shows these as three cards, and a side menu gives each one its own page. Read What you get — and what you don’t for the short version, and the Studio tour for captures of a real session.

A study has four steps, shown in a rail on the left: Framing, Study (the progress screen), Results and Use. A step that cannot be reached says why instead of staying silent.

Bring your data

• Drop or choose a CSV, or paste it. The file is read whole in your browser and sent as it is: the screen does not trim or truncate it. Anything that is not a CSV is refused by name.
• A preview shows the number of rows and columns and the first rows, and highlights the target column once you choose it.
• Try it first with the examples: two small samples of 250 generated rows (a credit-risk table and a “will it rain tomorrow” table; the data is generated with a known pattern plus noise, it is nobody’s data), and four measured public datasets with their source and licence (dresses-sales, climate-model-simulation-crashes, pc1 and, for regression, us_crime).
• In the downloaded Studio there is no cap on rows. The limit is memory, and each request accepts up to about 128 MB, and the Studio warns you before you start (see “Memory warning” below).

Say what you predict

• Target column: the exact name of the column.
• Type of problem: binary, multiclass or regression. Left empty, the core deduces it from the column or asks you.
• Positive class (binary only): which of the two values you want to detect, written as it appears in the column. Forms such as 0/1, Yes/No or capitalised labels are understood, and the screens, the batch file and the saved study show the labels as you wrote them.
• Unit of observation (required): what one row represents. It matters because the test set is split by rows, so one subject spread over several rows could end up on both sides.
• Prediction moment and horizon: required only when the data has a date column. They say from which point you predict and how far ahead.

Say how it is decided today (optional)

You can say there is no current process, point to a column that holds today’s decision or prediction, or write a rule. A column is taken out of the predictors so the model cannot copy it, and Results then compares the model with it on the same test rows. A written rule is noted but cannot be measured.

Quality, cost of error and constraints (optional)

• Intended use: one sentence. It changes nothing in the study; it travels with the problem, the saved study and the full download.
• A minimum the chosen model must meet, for example a floor on specificity. It is applied before ranking: if no candidate meets it, the study says so instead of crowning the least bad.
• Cost of a false positive and of a false negative (both 1 by default) and, optionally, the cost of reviewing a case by hand. With them the study chooses the decision threshold and, with a review cost, three decision bands: positive, to review, negative.

Confirm the target before you start

The “Confirm objective” button checks the problem against your data without training anything. Any later change erases the confirmation. The answer comes in four blocks:

• What blocks the study: a target that does not exist, that has a single class, that is an identifier or a date, or that has no usable inputs.
• What is left to decide: target, type of problem, positive class, unit, prediction moment or horizon.
• What stays out of the study, with the reason: free-text columns and the current-process column. They do not block; the study goes on with the rest.
• Things to keep in mind, including leakage warnings and the memory warning.

Free text. If a column was left out as free text, you can declare it as text, pick Spanish or English, and it competes with its own candidate. At most one text column per study.

Memory warning. If the study may not fit in memory, a note gives rows × columns, the estimated GB, the GB available and the measured dataset it leans on. It never blocks: you can always start.

Optional help from an LLM. If you configured a language-model provider in Settings, a checkbox lets it propose the empty fields (target, type, positive class, unit, moment, horizon). Before you tick it the screen states exactly what is sent: the column names, a few counts per column and five real rows of your CSV. Proposed fields carry a “Proposed by the LLM” badge until you edit them. Everything works without it.

What you do not choose

• The split is random, stratified by the target in classification, with 20% of the rows held out as a test set and 5-fold cross-validation on the rest.
• The Studio fixes the seed, the time budget (it grows with the size of the data), the hyperparameters of each engine and which engines compete (section 3). There is no screen to change them.
• Rows with no target are removed and counted; Progress and Results say how many. In regression, a target that is not a number in every row stops the study with a message.

While it runs

• The progress screen lists the engines and, under each, its parts with their status. It shows no quality figures while running, on purpose: they would change every few seconds.
• You can cancel at any time. If you reload the page, the Studio asks the server about the study you had running and picks it up again, or tells you the server no longer has it.
• A study of one of the demo examples takes about a minute and a half on the demo server (measured in September 2026 with two examples: about 90 seconds). Larger data takes longer.

Other engines exist in the engines library (XGBoost, CatBoost, a linear model, TabICL and an ensemble), but they do not enter a study today.

Which engines compete in each installation

How the winner is chosen

• Every engine is scored on the same cross-validation parts. The mean of the selection metric over the parts decides; the test set decides nothing.
• Tie-break against neural networks. If the best mean belongs to a network, it must beat the best tree by more than one corrected standard error (the Nadeau–Bengio correction, computed over the paired differences per part). Otherwise the tree wins, and an exact tie goes to the tree. Results shows a “Tie-break” badge and one sentence about it.
• The winner is refit and scored once on the held-out test set.
• A champion whose final model predicts worse than the reference, or that completes no epoch, is set aside and declared; the decision is then taken among the rest.
• An engine that runs out of its time budget is marked “ran out of time budget” and does not count as a bad score.
• Maturity. Each engine is labelled “supported” or “experimental” with the reason. A supported engine shows what Phase 0 measured for it; see How we measure.

When TabM sits out

• Memory guard. The Studio estimates the memory of the study. If it exceeds the limit set in Settings (100% by default), TabM stays out and Results says so under “Did not compete because of memory”.
• Time guard. TabM’s time per attempt is estimated from the size of the data. If it exceeds 800 seconds on CPU (1,800 seconds on a GPU), TabM stays out and Results says so under “Did not compete because of time”. TabM’s own time is added on top of the study budget, so no other engine loses time.
• GPU memory. If TabM is about to train on the GPU and the free video memory is not enough, it falls back to CPU, and Results gives the figures.

What the GPU does

Only TabM and the dense network use the GPU. The tree engines and the text engine run on CPU. If the GPU fails during a fit, the engine falls back to CPU and Results says which of the cases it was. No speed-up figure for the GPU is published, because none has been measured and declared.

Time budget

A study has a default budget of 180 seconds (140 for the search, 20 for the final fit, 10 for calibration, 10 for evaluation), shared among the engines by weight: the dense network gets a larger share. TabM’s deadline comes on top. If the setup does not fit in the budget the study fails out loud instead of trimming anything in silence. For very large data the budget grows with size.

How big, measured

The recommendation

• Champion: the winning engine by name, a plain description of what kind of model it is (a tree model says it is not a neural network and there is no network to draw), and the reason for the decision in words, written in your language.
• If there is no winner you read either “No model meets the minimum requirements” or “Insufficient evidence to recommend a candidate”, each with its reason.
• The engine’s maturity (“supported” or “experimental”), the tie-break sentence when it applies, whether a network was cut short by its deadline and after how many epochs, and where the network was trained (GPU or CPU, and why it fell back).
• Save this study keeps it so it survives a server restart (section 8).

The held-out test result

• A badge says what kind of evidence the figures are. “Independent held-out test” is the good one; the others (external validation, test already used, learned with the test, development estimate, not evaluated) are shown in amber.
• Binary: AUROC, accuracy and specificity at the study’s threshold. Multiclass: accuracy, log-loss and macro-F1. Regression: RMSE, R² and MAE. Every metric has a “?” to its definition.
• Prediction speed: how long one row takes on this machine and the time per row in a batch, with a note that the first prediction may take 1–2 seconds longer while libraries load.

The comparison

• One entry per engine: its maturity, the mean over its parts (marked as the one that decides), its spread from the lowest to the highest part, and an expandable list of every part with its status and its paired verdict against the champion (improvement, inferiority, practical equivalence, inconclusive, not comparable).
• Left out of the decision, with the reason: no time budget left, failed to fit, does not support the task, not installed here, did not run on every part, timed out on some part (“not for its quality”), final model predicted worse than the reference.
• Against what you do today: if you named a current-process column, the model is compared with it on the same test rows with paired resampling. In binary problems sensitivity and specificity are compared separately. It is retrospective, because today’s decisions shaped the outcomes, and a written rule is not evaluated.
• If a measured example was loaded, a Phase 0 card shows what each engine scored on that public dataset in the benchmark, which engine won there, and why your number can differ.

Risks

• Risk status: Blocked, Exploratory or Confirmed.
• Leakage warnings: probable identifier, very high association, probable proxy, predictive category by purity, duplicated target, unexplained equal values, a variable only available after the outcome, too few events, insufficient effective size, no lineage, insufficient precision, forbidden mixing of units.
• Segments: predefined and exploratory groups with their size, the metric inside the group against the rest, and a flag “worse than the rest” or “insufficient support”.
• Calibration: the expected calibration error (ECE) and the recalibration method. For multiclass problems it says calibration is not computed and the decision is the class with the highest probability.
• Conformal prediction: the promised coverage (90%), the measured coverage on the test set with a 95% interval, whether it is compatible with the promise, and the average set size (classification) or interval width (regression). It promises coverage on average, and only if new rows resemble the calibration rows.
• Decision bands (binary problems with a review cost): positive, to review, negative, with how many rows fall in each and the accuracy inside it.

The decision map

For binary problems whose winner does not read text and that have at least two numeric attributes, Results draws the model’s decision over two attributes. Each point is a test row (up to 1,000) coloured by its true class; the background shows what the model decides at each combination, with intensity for its confidence; a solid line marks where the probability crosses the study’s threshold. A circle means it was right, a cross means it was wrong, and a dashed ring means the row is outside the training range. Two menus choose the attributes, and the Studio picks by default the most informative pair and says which rule it used. With more than two attributes it is a slice: the rest are held at a typical value, which is listed. Otherwise the screen says why there is no map.

Evidence

The evidence block lists the package checks that were run (integrity) and the ones that were not, and shows the receipt of the study, signed or unsigned, with the reason when it is unsigned. The receipt is signed with the key you configure for your installation. See The proof for what a receipt holds up and how it is verified.

What Results does not show

Results has no ROC curve, no confusion matrix and no calibration curve, no comparison between two studies, and no export of the comparison table. The column importance of the model itself is on the Use screen and only exists for LightGBM.

The Use screen offers only what is really possible with this winner. The list on Results says which ones.

Try one row

• One field per input column of the model. Numeric fields accept a decimal comma and, when the study kept the range, show a slider and the range seen in training; categorical fields offer the categories seen in training; date fields tell you the format; a text winner gets a text box.
• The fields start with sample values (the median of each numeric column, the most frequent category) with a button to return to them. An empty field is treated as missing data, not as zero, and the screen says so.
• Binary result: the prediction with the original class name, the calibrated probability, the raw probability and the study’s threshold. Multiclass: the probability per class. Regression: the predicted number.
• Also shown when they exist: the conformal set or interval for that row, the decision band, and a “what was seen” check that tells you whether every value is within what the model saw in training (new category, out-of-range value, empty value that was never empty).

Predict a whole CSV

Choose a second CSV and press Predict. The whole file’s schema is validated before predicting: missing or extra columns are listed one by one. Rows are predicted one at a time, so one bad row does not stop the rest. You get a summary (rows predicted, rows with an error, rows per band, rows with something unseen) and a CSV to download with the original labels, a band column and a column that flags rows outside what the model saw.

Which columns weigh, and the network drawing

• Which columns weigh in this model: available only when the winner is LightGBM, with total gain and number of splits per column. It says what this model did with these data, not causal influence.
• The network of this model: a layer-by-layer drawing, only when the winner is the dense network. TabM and the tree models have no drawing.

Save and take the model with you

• Package: a folder with the model, its data preparation, a prediction script that gives the same answer as the screen and a dependencies list, downloadable as a zip. Binary, multiclass and regression studies can all export a package. The package check that is run is integrity; the rest are declared “not checked”.
• Prediction in the browser: only when the winner is LightGBM. The Studio converts the model to ONNX and measures its parity with the Studio’s own model on real rows before offering the page. You can open the page or download it as a single HTML file. It loads ONNX Runtime Web from the internet, so it does not start offline.
• Serve the model with Docker: a zip with a Dockerfile, a small server and the inference package. A token of 16 characters or more is mandatory; without the header the service answers 401. Image sizes measured: about 544 MB with HGB, 622 MB with LightGBM, 1.68 GB with TabM or a network (PyTorch), and about 8.9 GB for a network trained on a GPU.
• Take the whole study to another Studio: a zip with the comparison, the note, the winning model, test rows and a manifest. It is imported into a Studio; it is not run on its own. The screen lists beforehand which of your data travels (up to 2,000 test rows without the target, the categories seen, the minimum, maximum and median of each numeric column, and for binary problems the decision-map file), and warns if the scanner finds something shaped like a key or password.

The online demo does not export packages, pages, services or studies; they are part of the Studio you download.

The lab trains your own network, the one you designed from a sentence, a CSV or a template, with editable training settings. You compare run with run and look inside what training measured. It is experimental and for learning: the best model of your data is found in the study. The lab has its own page, reached from the home card or from “The lab” in the side menu. The step-by-step build of a model is in the phases manual.

The seven training settings

• Each field shows the value that will be used if you do not change it and says whether it is required. The server checks the ranges. Errors appear next to the field and “Train” stays off until they are fixed.
• A number is read according to the language of the screen (decimal comma and thousands dot in Spanish, the opposite in English), and the screen tells you how it read what you typed.
• The same seed repeats a run exactly; “Try another seed” picks a new one. Loss function, architecture, early stopping, momentum, gradient clipping and dropout are fixed by the model and cannot be changed here.
• Without PyTorch, the lab trains with plain SGD, one example at a time, and the controls it cannot honour (Adam, AdamW, weight decay, schedule) are switched off with their reason written next to them.

Suggested experiments

Six ready-made experiments, each changing one thing with the seed fixed so you can tell the cause: a very high learning rate, a very low learning rate, a large batch, Adam instead of SGD, more epochs with Adam, and another seed. Each says what usually happens (never a promised result) and what to look at. “Prepare this experiment” only fills the settings; it does not train. They were measured on classification (climate) and on regression (us_crime), and the screen gives what to expect for each task.

Curves and metrics

• Two curves for the current run: the loss (training and validation per epoch, with the best epoch marked and divergence reported if the loss stops being finite) and, depending on the problem, the accuracy or the validation error (regression).
• A plain-words reading of the curves once the run has finished.
• Classification metrics: accuracy and macro-F1, a confusion matrix, and precision, recall and F1 per class, plus a reference: what always answering the most frequent class would score. If the model collapsed to a single answer the card says so. Regression: MAE, RMSE and R².
• A value that is missing is shown as a dash, never as a zero.

Run history and comparison

• Every finished run leaves a card saved with the model, with the last 20 kept. Tick up to 5 to overlay their curves: one colour and one line style per run, a marker on each best epoch, a switch for training, validation or both, and an optional logarithmic scale.
• “What changes between these runs” lists only the settings that differ, and warns when two or more things changed at once (you cannot know which caused the difference) or when the runs used different networks or different rows.
• The best run of the history is named with its criterion in words, chosen only among comparable runs (same task, same figure, same rows, same data). A best run that does not beat answering the most frequent class is flagged as such.

Inside the network

• Weights per layer, for a sample of epochs (the first, the best and the last, among others).
• Walk of one row through the network: pick a validation row, or type one in prepared form, and see each neuron’s activation layer by layer up to the output.
• How each layer learns: the gradient norm per layer and epoch, with what it is and is not (it is not how much the weights move).
• Available for your own dense network on a finished run with PyTorch. TabM has no settings, per-epoch curves or “inside” view.

A bridge to the study: “Try the MatrixAI network (TabM)”

From the lab you can choose TabM instead of your own network. That opens a one-engine study with the data of your model, measured against the reference. It tells you how long it usually takes for your size of data, and it delivers a model only if TabM is strictly better than the reference. When it ends, the result goes back into the history of your model.

What the lab does not do

No optimizers beyond SGD, Adam and AdamW, no other schedule than cosine, no early stopping, dropout or loss choice, no automatic sweep of hyperparameters, no zoom or export of curves, no deleting or annotating a single run, and no resuming a cancelled run. It trains tables, not images or raw text.

A risk score that a hospital, a bank or a vendor gives you was measured on other people. This check contrasts it with what actually happened in your cases. It trains nothing, needs no model and does not change your score: it measures what you already record. A simulated version, run in your browser, is on the “Does it work here?” page.

What you bring

• A CSV with one row per case: a binary observed outcome, one or two score columns and, optionally, columns to define subgroups.
• Declarations that you make, because the Studio never deduces them from the values: which value is the event, whether the score is a probability, a percentage or a points scale, whether higher or lower means more risk, when the score was computed, the outcome horizon, and whether the sample represents the population where you would use it. If you do not declare something required, the check is not built.

What it measures

• Ranking: does the score put the cases with the event ahead (AUROC and average precision).
• Calibration, only for a probability: whether a given probability matches how often the event occurs.
• At the threshold you use today: sensitivity, specificity and, if the sample represents the population, the positive and negative predictive values, with their confusion matrix.
• Subgroups: with whom it fails. A subgroup needs at least 30 rows with 10 events and 10 non-events to report a figure.
• Two scores: whether one improves on the other, with a paired comparison.
• Intervals are 95% bootstrap intervals with the seed recorded in the report.

What you get

A report in Spanish and in English, shown on screen and downloadable as HTML, and a receipt with the fingerprint of your CSV, your declarations, the seed and the versions used. The report says what it is not: it is not a clinical validation or a regulatory evaluation; it warns about the treatment paradox (if the score already drove decisions and the treatment prevented the outcome, the score will look worse than it is); and it depends on how the outcome was recorded. The receipt is signed with the installation’s key if there is one; otherwise it is unsigned.

Where your file goes

In the Studio you download, the CSV stays on your computer. In the online demo, the CSV leaves your computer for the demo server, is processed in memory and discarded, with size limits and a notice not to upload patient or personal data. The report and the receipt hold no rows, only aggregates.

It does not do: multiclass, regression or survival outcomes; recalibrate and give back a corrected score; connect to a database (CSV only); run a model file; sign for third parties with an asymmetric key.

Under “Your library”, the page Saved has two lists, each one kept where it belongs.

• Saved studies (Studio you download): name (by default the target and the date), description, date, engine, metric and task. You can open a study to use it (try a row, predict a CSV, see which columns weigh, download the package or open the browser page), delete it after a confirmation, or prepare its zip. A study that cannot be reopened, for example because its engine was retired, says why. A saved study is only opened to be used: it is not edited or retrained.
• Import a study from a zip that another Studio produced. The importer refuses a zip that is too large (64 MB) or that expands beyond 512 MB, accepts only the permitted parts, and says when the study was already in the list.
• Saved checks (“Does it work here?”): each finished check is saved by itself, on your computer in the downloaded Studio and in your browser in the demo. You can view it exactly as it was calculated, delete it, or modify and repeat it. In the Studio you download you can also keep a copy of the CSV with the check (the box is ticked by default and the copy stays on your computer). If you did not keep it, repeating the check asks for the same file and compares its SHA-256 fingerprint before using it.

Saving, opening and importing studies are not available in the online demo. Saving a study never changes it, and no study can be shared as a link.

• Phases interface: the default in the downloaded Studio and the only one in the demo. Its expert-mode flow (model, data, training, audit, test, deployment, follow-up) is in the phases manual.
• Workbench: a third interface with movable panels and a tab per model, in the packages only and marked experimental. See the Workbench manual.
• Classic interface: the original one, reached only by typing its address in the packages. It is kept as it always was.

What happens to a model once it is out is in After you deploy, and the rule that decides the target of generated data is in the data recipe manual.

The Studio you download comes as two packages, CPU and GPU, both run with Docker. PyTorch is not inside the zip: it is downloaded on the first start, on the computer that installs it. The Quick start walks through it, and the downloads are on the home page under pricing. The online demo shows the same screens on a restricted footing.

A limit profile in Settings (balanced by default, advanced, unlimited) caps what is costly to compute, such as epochs, depth, parameters and TabM’s memory guard. The demo keeps hard caps of its own.

A study says what was measured and on what; it never promises that a model is good. These are the things the Studio does not do today.

• You do not pick the engines, the time budget, the number of folds, the seed or the test fraction, and you cannot search hyperparameters.
• Split: random, stratified in classification. No temporal split, no split by group, no external cohort. Asking for a temporal or group split fails with an explanation.
• Data: CSV only (no Excel, no databases or APIs, no several tables). No time series, images, audio, documents, multi-label targets or quantile regression. At most one text column, and it is not mixed with the table columns in one model.
• Calibration and bands: no calibration for multiclass problems, and decision bands only for binary problems with a review cost.
• Studies: no retraining or editing of a saved study, no comparison between two studies and no history of studies beyond the list of saved ones.
• Explaining the model: column importance only for LightGBM; no drawing of TabM or of trees; the browser page only for LightGBM.
• Beyond training: the Studio packages models and, from expert mode, can publish them to Hugging Face, but it does not deploy them to production by itself. What happens once a model is out (registry, continual policy and drift) is in After you deploy.
• It is not a clinical or regulatory validation, and none of the reports claims to be. For what the documentation artefacts cover for the EU AI Act, read EU AI Act.

The Studio runs on the open-source core, MatrixAI core, which you can use without the Studio. It has no mandatory dependencies, works without a language model (deterministic mode) and is licensed AGPL-3.0.

Install

• pip install matrixai-core, Python 3.10 or later. Optional extras: [export] (ONNX, ONNX Runtime and NumPy) and [torch] (PyTorch).
• Run it as matrixai <command> or python -m matrixai. Language-model providers are configured through MATRIXAI_LLM_* environment variables or a .env file; without a key the deterministic engine is used.

Command-line commands

Every command with real examples is in the CLI reference; runnable recipes are in the API cookbook.

The HTTP server

matrixai serve exposes POST /predict, POST /execute-action, POST /feedback, GET /health, GET /metrics (Prometheus), GET /docs and GET /openapi.json, and, under /api/v1/, the registry (list, tags, detail, pull, push, verify, predict and tag). Options include --port (8000), --host (127.0.0.1), --api-key (a Bearer key, generated if you give none), a read-only key, --rate-limit (60 per minute per IP by default), --cors-origin, --registry, --signing-key and --allow-real-actions. The whole lifecycle is in the REST API reference.

The core as a library

• The study itself: matrixai.estudio holds the competition, cross-validation, selection, decision bands, conformal prediction, calibration, threshold and final report that the Studio uses.
• Generation and training: a sentence or a CSV to a model (generation, agents, training), with the data recipe written by hand (data recipe manual).
• Export: ONNX, WebAssembly and a self-sufficient bundle with a prediction script and an inference specification.
• After deployment: a versioned and signed registry, continual-learning policies with drift detection (accepting a suggestion creates a candidate, never a deployment), and deterministic pipelines that name the rule that fired.
• Trust: DSSE signatures with a rotatable keystore, receipts with an assurance level A0 to A4 that is deduced and never declared, a sandbox that says per action what is allowed and why, and a resource estimator for VRAM, RAM, disk and time.

Continuous integration

The matrixai-verify GitHub Action verifies a reproducible package in your pipeline. Inputs: the package, the scopes that must have been performed (manifest,R1 by default; it can only tighten), whether to retrain, and the language. Outputs: a verdict (VERIFIED, PARTIAL, FAILED or NOT VERIFIED), an exit code (0 all that was required was performed and nothing failed, 1 it could not start, 2 something checked was wrong, 3 something required was not performed) and the scopes not performed. It needs matrixai-core 1.8.0 or later and never reports more green than matrixai verify.

For how receipts, verification and reproducible packages work, read The proof and the Cases you can redo; for the agents behind the sentence-to-model flow, Agents; and for every function the language can run, Math functions.