What a model looks like in Subspace

When we talk about analytical models, projections, or simulations, a lot of the conversation stays abstract.

We talk about logic, execution, scenarios, integration, results.

At some point, though, things need to become concrete.

You need a clear answer to a simple question:

what does a model in Subspace actually look like?

In many environments, the problem isn’t only the calculation

In many organizations, business logic ends up buried:

• in files
• across multiple sheets
• in scripts
• in scattered rules
• in tweaks that are hard to trace
• in flows few people can skim quickly

The model may still work.

But its structure becomes hard to read, hard to reuse, and hard to evolve.

So the issue isn’t only what the model computes.

It’s also what shape that logic takes.

Another approach: make the logic easier to see

In Subspace, the goal isn’t to hide logic behind a black box.

The goal is to make it clearer, more structured, and more reusable.

A Subspace model states explicitly what should run:

• the number of scenarios
• the number of steps
• the variables
• the distributions
• the formulas
• the expected outputs

In other words, the logic doesn’t vanish into its container.

It becomes a more readable object.

What a simple model looks like

Take a deliberately simple example.

We want to project capital over 12 steps, with 1,000 scenarios.

The rate follows a uniform distribution between 3% and 7%.

Capital evolves each step using that rate, then we compute profit.

In Subspace, that logic can be described like this:

{
  "steps": 12,
  "scenarios": 1000,
  "variables": [
    {
      "name": "rate",
      "dist": "uniform",
      "params": {
        "min": 0.03,
        "max": 0.07
      },
      "per": "scenario"
    },
    {
      "name": "capital",
      "init": 1000,
      "formula": "capital[t-1] * (1 + rate)"
    },
    {
      "name": "profit",
      "init": 0,
      "formula": "capital[t] - capital[0]"
    }
  ]
}

The model isn’t only executed. It’s described.

What matters here isn’t only the JSON itself.

What matters is that you can clearly see:

• the simulation parameters
• the variables
• the evolution logic
• how the pieces relate

The model becomes easy to read back.

The same model in the portal

In the Subspace portal, that same logic can be viewed in several ways:

• spreadsheet view
• diagram view
• results
• charts

That lets different roles work with the same model depending on what they need:

• structured reading
• understanding dependencies
• validating results
• fitting into a workflow

Spreadsheet view: zoom on the Model grid

The hero image sets the portal context; the screenshot below zooms in on the grid: scenarios, steps, and the taux / capital / profit columns (the same logic as rate, capital, and profit in the JSON above).

Diagram view: dependencies between variables

Results and charts after a run

The important point isn’t that the interface looks nice.

It’s that the portal rests on the same logic described in the model.

What that changes

When a model is better structured:

• it’s more visible
• it’s more portable
• it’s easier to change
• it’s easier to read back
• it’s more natural to integrate
• it’s less tied to one file or one person

The model is no longer stuck in a file, a script, or implicit logic.

It becomes a clearer structure that can live in multiple contexts.

It’s not only “neater”

This can sound cosmetic or technical at first glance.

But it has very concrete consequences.

When logic is described more clearly:

• changes are cheaper to absorb
• reuse gets simpler
• integrations need less rebuilding
• understanding the model improves
• maintenance becomes less fragile

So better structure isn’t only a comfort.

It’s also a way to reduce the load around the model.

What a structured model enables

Once the model is described clearly, it can be:

• run in the portal
• called via API
• used from a Python script
• embedded in a TypeScript app
• picked up in another workflow

So the model isn’t only something you read.

It’s executable logic that can move through the organization more cleanly.

Conclusion

Past a certain level of complexity, the question isn’t only:

does the model work?

It’s also:

what structure does it live in, and what does that structure allow?

In Subspace, a model isn’t only a calculation hidden behind a UI.

It’s logic described more clearly, runnable on a shared engine, and reusable across contexts.

That’s what makes it worth sustaining over time.