At HASH, we started life building agent-based models (ABMs). Although we've shifted our focus to graph-based simulation and Process Foundation Models (PFMs), ABMs remain the clearest lens for a problem that doesn't disappear when the modelling tool changes: the inverse problem of recovering a system's hidden mechanisms from the data it leaves behind. The technical challenges that make inverse problems hard in ABMs carry over, almost one for one, to PFMs. Throughout this post we use ABMs as a worked example, concrete enough to build intuition while faithful enough that the lessons transfer. The goal is to lay out why these problems are hard, and why solving them is what makes a model make contact with reality at all.

Agent-based models

Agent-based models are simulations of individual agents and their interactions within an environment over time. Each agent carries a set of parameters. Rules govern how agents interact, and those interactions update each agent's state. The initial state of each agent is given by initial conditions. Run all these local interactions forward and a larger structure emerges — collective, aggregate behaviour that no single agent dictated. Here are some examples of each component of an agent-based model:

• agents: people, suppliers, factories, warehouses, products.
• interaction rules: traffic conservation laws, i.e. vehicles in equals vehicles out of a junction, logic-based rules, e.g. once a product is purchased, warehouse inventory for that product drops by one unit.
• environment: space represented as a graph.
• parameters: inventory capacity for a warehouse agent.
• agent states: in production / en route / delivered state for a product agent.
• initial conditions: raw material quantities located at a factory location.
• emergent structure: inventory cycles, congestion waves, demand cascades.

What makes ABMs valuable is precisely what aggregate models throw away. Compartmental or mean-field descriptions (e.g. a set of differential equations) assume homogeneous, well-mixed populations. ABMs instead retain heterogeneity between individuals, local and network structure, spatial detail, stochasticity, and adaptation. These features matter whenever non-linear collective phenomena depend on who interacts with whom, rather than just on average rates. They also let you run controlled in-silico experiments, that is, "what-if" scenarios to assess the effectiveness of policy interventions you couldn't run ethically, cheaply, or at all in the real world. It's this fidelity to individual behaviour that makes ABMs and other modelling approaches such as Petri net simulations a natural fit for the socio-physical systems HASH models — supply chains, manufacturing, logistics, and the transport networks that tie them together.

Inverse problems and why we care about them

Running a process model is the forward problem (see solid arrows of Figure 1 below): given parameters and initial conditions, simulate forward and produce outputs you could in principle observe. This is what an ABM does every time you press "run". But in almost every real application this is the wrong direction. We do not start with known parameters; we start with data — observed outputs — and we want to recover the mechanisms, parameters and initial conditions that produced them. That backward direction is the inverse problem (see dashed arrows of Figure 1), and it is where a model actually makes contact with reality. Inverse problems aim to recover the underlying causal factors that generated an observed structure and comprise the so-called latent space. Broadly, there are three kinds of "causes" that control the output:

• parameters attributed to each agent or defined globally.
• temporal agent states control the output at time step .
• initial and/or terminal conditions.

Regarding the last cause, so far we have only discussed initial conditions—but an ABM's terminal conditions may be fixed too. An ABM can be run as a pure forward simulation, where you specify only the initial state of the agents and environment and let the dynamics play out, producing whatever emergent behaviour they happen to produce with no constraint on where the system ends up. Often, though, you also have a target or terminal state in mind—a condition the system is expected (or required) to reach. In these cases the model takes both initial and terminal conditions as inputs, which can be used to calibrate, constrain, or validate the trajectory in between.

Without solving the inverse problem, an ABM is an elaborate "what if" generator with no anchor to the system it claims to describe. Indeed, you can view much of empirical science itself as one large inverse problem — inferring hidden causes from observed effects.

What inverse problems does a PFM solve

A Process Foundation Model (PFM) learns a reusable latent state of a structured, evolving system from observations of that system over time. Recovering that latent state from what we can observe is, in every case, an inverse problem. Below we pick out three of them.

A quick word on the modelling language first. A natural way to describe a process is a Petri net: places hold tokens (the resources or items flowing through the system), transitions are the events that consume tokens from input places and add tokens to output places when they "fire", and a marking is the snapshot of how many tokens sit in each place at a given moment. Firing rates govern how quickly transitions occur. Run a Petri net simulation forward and you get a trajectory of markings; the inverse problems below all run that direction in reverse: from observed behaviour back to the structure, parameters, or state that produced it.

The first of these is the most fundamental, because it tackles process discovery: recovering the shape of the process itself, not just its settings. If you are interested in this problem you can read more about our approach here.

Why are they hard to solve

Let's return to ABMs and look at why inverse problems are hard to solve in that setting. In the discussion below, we identify many challenges that carry over to inverse problems in Process Foundation Models.

Modelling real-world systems with ABMs raises a host of interrelated challenges (Banks et al., 2021). Broadly, they stem from three sources: the intrinsic complexity of the systems being modelled, the data we can realistically collect from them, and the difficulty of turning either into actionable insights. We treat each in turn below.

Complexity & computational cost

Socio-physical systems are complex, and to capture that complexity at the scale and resolution real applications demand, ABMs get expensive — a single simulation can take hours (An, 2021). That cost has a sharp statistical consequence: the ABM likelihood is usually intractable, meaning you simply can't write it down. The simulators that do have tractable likelihoods are the ones too simple to describe anything interesting. And because every run is costly, you only get to run the model a handful of times — so where you choose to run it, at which parameter and initial-terminal conditions, becomes a question worth designing carefully.

High-dimensional, mixed spaces

That complexity shows up in the inputs too. The input space is high-dimensional because inputs are agent-specific — agents are heterogeneous, so the number of inputs grows with the number of agents. That alone creates identifiability problems: you can fail to recover the true parameters even with infinitely many observations (Raue et al., 2009). It's also a mixed space. Initial-terminal conditions and agent attributes tend to be discrete, while parameters are continuous, and modelling both together means building covariance structures across discrete and continuous variables — something there's no clean recipe for (Cox & Wermuth, 1974).

Spatio-temporal variation

The outputs are high-dimensional as well, and they vary across both space and time. That variation often has a Markovian flavour, the kind hidden Markov models exploit (Rabiner & Juang, 1986) — but actually sampling agent states at each time point is hard. Residuals aren't always Gaussian (Lux, 2018), so you fall back on approximate sampling, and the curse of dimensionality makes sampling harder the more agents you have. To make matters worse, not every ABM can be written hierarchically, so you can't always get at the time-dependent distribution of agent states. Without those conditional-independence shortcuts, the non-hierarchical alternatives don't scale either (Grazzini et al., 2017).

Uncertainty

Because the same inputs can produce very different outputs, you can't read off a single answer from one run — you need an ensemble to approximate the output distribution (Sung et al., 2024). And that distribution is often multi-modal, so you need sampling methods careful enough to find every mode rather than getting stuck in one (Dunbar et al., 2022). Quantifying this uncertainty matters to two audiences at once: decision-makers, who need to know how far to trust the emergent structure they're shown, and modellers, who use it to decide where to run the simulator next.

Mechanistic structure

ABMs come loaded with mechanism — macroscopic physical laws and microscopic behavioural rules — and good inference has to respect both (Hooten & Wikle, 2010). The catch is that you can't always turn that mechanism into a smooth likelihood or prior, because if-then-else rules and phase transitions introduce hard discontinuities (Bonabeau, 2002). Often you don't even know where those transitions are in advance, so finding them becomes its own inference problem (Evangelou et al., 2024).

Sparse, noisy, multi-fidelity data

Then there's the data itself. High-resolution observations are rare; most of what you get is low-resolution (Grazzini et al., 2017), largely down to privacy, security and the cost of collection. Sparse data brings back the identifiability problems from before, and often forces you to interpolate, extrapolate, or augment just to give the model enough to work with (Cocucci et al., 2022). The convenient Gaussian-noise assumption tends to break, too. And learning discrete variables from aggregate data makes the space of possibilities blow up combinatorially (Zachos et al., 2024) — something we'll come back to later.

Together, these challenges are why inverse problems for ABMs are ill-posed. This is a notion that captures three failure modes, in which a solution to the inverse problem:

• may not exist
• may not be unique, or
• may not depend stably on the data.

Non-uniqueness is the failure mode most central to what follows: many different parameter sets, or even different mechanisms, can produce indistinguishable outputs. The parameters, initial-terminal conditions or agent states are then non-identifiable — the data simply cannot pin down the latent mechanism that generated them, which is exactly what any meaningful prediction system requires.

The example of initial-terminal condition inference

To see why inverse problems bite, it helps to look at one concrete piece of the latent space: the initial-terminal conditions. For the sake of argument assume that agents are people travelling from their home/origin (initial state) to their work/destination (terminal state). So what are we actually trying to recover here?

The mathematical object is called a contingency table (CT - see Figure 2 below). A -way contingency table is just a -dimensional tensor of counts: each agent attribute takes values in some finite set, and the entry at a given position records how many agents have exactly that combination of attributes. In the example of Figure 2, we have a three-way contingency table with agent attributes being the origin node (home location), destination node (workplace location), and age group. The entry at index counts the number of agents in the first age group ( years old) starting from origin node to destination node . Think of it as a fully cross-tabulated headcount of the population.

Why is this an inverse problem? The full contingency table is typically unknown to us. It gets collapsed by a summary-statistic operator down to the resolution of the data we actually have — a far coarser, aggregated view. Inference has to run backwards through that collapse: from sparse, aggregated counts, recover a high-dimensional discrete tensor of who-was-where.

In a very simple scenario, we know the population of agents living in, say, Cambridge (this is a summary statistic), but do not know how many of them in the ages 18-25 travel to London for work (this is the full contingency table). Figure 3 shows what we know and what we don't.

What are the challenges here? Let's consider them one by one.

Observation and latent-space resolution discrepancy

The first problem is that what we want and what we see live at different resolutions. The latent object is the full joint table — every origin paired with every destination, broken down by age. The data, on the other hand, usually arrives pre-aggregated: a census tells you how many 18–25 year-olds live in Cambridge and how many people work in London, but not how many Cambridge 18–25 year-olds commute to London specifically. Those are the red cells in Figure 3 (row and column totals) while the joint counts we actually care about are the blue cells inside.

Formally, the summary-statistic operator throws information away on its way from the table to the data, and it isn't invertible: you can't just undo the aggregation to read off the cells. The mismatch is often worse than a single clean projection, too. Real data is multi-fidelity — a few high-resolution surveys here, coarse population totals there — so different parts of the table are constrained at different granularities, and large stretches aren't pinned down by anything direct at all. Inference has to bridge that resolution gap, reconstructing fine-grained structure that the observations only ever describe in aggregate.

Combinatorially large design spaces

Bridging that gap would be fine if the aggregated view narrowed things down to a handful of candidates. It doesn't. Because the unknowns are discrete and the evidence is aggregate, the set of tables consistent with what we observe explodes combinatorially — many wildly different contingency tables reproduce the same summary exactly. That's non-uniqueness in its starkest form, and it's why initial-terminal condition inference is a textbook ill-posed problem rather than a routine fitting exercise.

And that's the toy case. Ten agents and five choices already gives nearly ten million configurations; a realistic city has agents in the millions and choices in the thousands, so the space we're searching over isn't just large — it's astronomically larger than anything we could ever enumerate. We can only ever simulate or evaluate a vanishing fraction of it, which is exactly why where we choose to look matters so much.

Hard-constrained space exploration

There's a final twist that makes the search harder still. We can't roam this enormous space freely, because the observed summary statistics aren't just hints — they're hard constraints. Any table we propose has to reproduce the red cells in Figure 3 exactly: every row of blue counts must sum to its observed origin total, every column to its observed destination total. A configuration that gets the joint counts "almost right" but breaks a margin by even one agent isn't a slightly worse answer — it's an invalid one.

So we're not exploring a nice open space; we're confined to the integer points sitting inside a polytope carved out by the margin constraints. That changes the nature of the problem completely. Ordinary sampling moves — nudge one cell up a little — almost always land outside the feasible set, because adding an agent to one cell violates the totals unless you simultaneously remove one elsewhere. Valid moves have to be coordinated across multiple cells at once to keep every constraint satisfied, which is precisely what makes naive search and standard samplers stumble here. Exploring this constrained, discrete space efficiently by proposing moves that stay feasible while still mixing across the full range of valid tables is the core technical challenge that any solution to initial-terminal condition inference has to solve.

How challenges carry over to PFM inverse problems

At HASH, we've moved away from ABMs, but the technical challenges we identified earlier in inverse problems transcend the boundaries of ABMs. We discuss each challenge's relevance below.

Intractable likelihoods and costly forward runs. A stochastic Petri net is a simulator like any other: run it forward and you get a trajectory of markings. You cannot always write down the likelihood of an observed event log in closed form. If you can, then you might encounter an intractable probability distribution normalising constant that introduces a computational bottleneck. So parameter inference inherits the same intractable-likelihood, expensive-simulation regime as ABM parameter estimation. The consequence is identical too: every run is precious, so where you evaluate the model is an experimental design question.

High-dimensional (combinatorial), mixed spaces. The latent space of a Petri net is heterogeneous in exactly the way an ABM's is. Structure is discrete (which places, which transitions, and how they're wired), firing rates are continuous, and markings are non-negative integer counts. Recovering them jointly is the same discrete-plus-continuous covariance problem from before, and it carries the same identifiability risk: distinct latent configurations that no amount of data can tell apart.

The discrete axes are also where combinatorial explosion creeps in, and in a PFM it surfaces in a second place: intervention validity. The space of candidate actions a PFM might recommend - a rerouting, a deployment, a policy change — is itself discrete and high-dimensional, so exploring it exhaustively is as hopeless as enumerating every warehouse configuration. Navigating it efficiently becomes the whole game. My previous work on Markov bases speaks directly to this. A Markov basis supplies a set of moves that traverse a constrained discrete space while never leaving the feasible region, which means you can explore that space by Markov Chain Monte Carlo (MCMC) without ever proposing an invalid configuration — the same hard-constraint problem from the contingency-table example. That gives the PFM's intervention space a natural exploration strategy. Such a strategy works well because hard constraints are encoded in the exploration by construction, enabling efficient constrained space exploration.

Spatio-temporal variation. Markings evolve over time with a Markovian dependence since the next marking depends only on the current one and on which transition fires. Token distribution inference, reconstructing where the tokens actually sit from partial observations, is the Petri net analogue of sampling agent states through time, and it runs into the same curse of dimensionality: the more places and tokens, the harder the state is to sample.

Uncertainty and multi-modality. Many markings, many rate vectors, and many whole net structures can explain the same observations equally well. So no single run is an answer; you need an ensemble to approximate the posterior, and that posterior is frequently multi-modal — demanding samplers careful enough to find every mode rather than collapsing onto one. As with ABMs, quantifying this uncertainty serves two audiences: decision-makers calibrating how far to trust the recovered process, and modellers deciding where to look next.

Mechanistic structure and hard discontinuities. Petri net firing semantics are mechanistic: they encode which events are possible and how tokens move when those events occur. Extensions can add continuous dynamics, but even the discrete firing rules alone can introduce discontinuities and threshold effects, resisting being smoothed into a clean likelihood or prior.

Sparse, noisy, aggregate data. Event logs are partial, traces are noisy, and performance measurements are aggregate. The result is the same ill-posedness: a solution may fail to exist, fail to be unique, or fail to depend stably on the data — with non-uniqueness, again, the failure mode that bites hardest. Process discovery is its sharpest expression: the space of Petri nets consistent with a finite log is combinatorial, exactly as the space of contingency tables consistent with a set of margins was.

In a PFM this problem materialises as an observation and latent-space resolution discrepancy: what we want to recover and what we actually observe live at different resolutions. The latent space is fine-grained — the net structure, firing rates, and a marking that says exactly how many tokens sit in each place — while the data arrives coarse, summed and binned down to whatever granularity is cheap, safe, or legal to collect. A summary-statistic operator maps the high-resolution latent object onto the low-resolution observation, and that operator is not invertible: it discards information on the way down, so you cannot simply undo the aggregation to read off the tokens, rates, or structure you care about. The discrepancy is rarely a single clean step, either. Real process data is multi-fidelity — a few detailed traces here, coarse throughput totals there — so different parts of the latent space are constrained at different resolutions, and large stretches aren't pinned down by any direct observation at all. Inference has to bridge that resolution gap, reconstructing fine-grained structure from evidence that only ever describes it in aggregate — precisely the difficulty the worked contingency-table example above makes concrete.

What's next

Having established why a PFM's inverse problems are hard, we'll turn to how we solve them. Our newly founded AI lab will be researching the methods that make this constrained, discrete, high-dimensional inference tractable, and what they buy us when a PFM is finally pointed at a real supply chain, factory, or transport network. If you'd like the bigger picture in the meantime, our overview of Process Foundation Models is the place to start.