From terms to diagrams

Nearly every programming language represents a program as a term, a tree-like structure. The tree records what the program is; how it runs is settled elsewhere—by reduction, by evaluation, by whatever mechanism an interpreter or compiler chooses—outside the syntax, and taken on faith.

Term syntax also makes a quiet assumption: that data may be copied and discarded at will. A variable may appear twice in a term, or never. Much of computation is not like that—a resource consumed cannot be reused, a message sent cannot be unsent—and category theory has long had a syntax for such situations: string diagrams for monoidal categories, that is, nodes joined by wires, each wire carrying a value, exactly once, from one operation into the next. Terms are the special case in which every wire comes with copying and discarding operations.

The second step is to go up in dimension. A string diagram is already a two-dimensional object, having besides its nodes and wires the regions of the plane that the wires bound. Once regions, wires, and nodes are counted as cells of dimension 0, 1, and 2, there is no reason to stop counting. A pasting diagram has cells of every dimension, each bounded by an input and an output face: a point, an arrow between points, a filled surface between two paths of arrows, a solid between two such surfaces. Each level, moreover, reads as a rewrite of the level below—an arrow carries its source to its target, a 2-cell carries one path of arrows into another—so that every storey of the tower, however high one climbs, is the same kind of object. (The counting is by role rather than by drawn shape: the string diagram is the Poincaré dual of a two-dimensional pasting diagram, with regions standing for points, and nodes for 2-cells.)

This is the entire ontology of the language: one kind of thing, the diagram, and one non-trivial operation upon it, subdiagram search, which finds a diagram sitting inside another. The whole rests on a single observation, the founding principle of higher-dimensional rewriting:

a computation on n-dimensional data is itself (n+1)-dimensional data.

In every other model of computation that I know of, a program and a run of that program are objects of different kinds: usually, a piece of syntax on one side, a sequence of machine configurations on the other. Here they are the same kind of object, one dimension apart, and the run is data again, ready in its turn to be computed on.

An alphabet of two letters

A type in alifib is a diagrammatic signature, a collection of building blocks of increasing dimension from which diagrams can be assembled. Let us look at a simple 2-dimensional example, essentially an encoding of a string rewrite system. Here is a type with a point pt, and two arrows a, b from the point to itself, so that words, that is, strings of as and bs, are one-dimensional diagrams. A rule of grammar for these words is nothing but a two-dimensional generator:

@Type
Letters <<= {
    pt,
    a: pt -> pt,
    b: pt -> pt,
    (* a rewrite rule is just a 2-dimensional generator *)
    swap: a b -> b a
}

swap rewrites the pattern a b, wherever it occurs inside a word, into b a. Note what is missing: there is no separate register in which “evaluation rules” are declared, no computation mechanism external to the type. The rule and the data it acts on are generators of one type, a dimension apart. A point, two letters, and one rule are very little, but they are enough to compute with.

Watching it run

Begin an interactive session on the word a b a b. The visualisation pane draws it as a string diagram, while the engine searches out every position at which swap matches, and lists them. This is subdiagram search at work; everything else in the system is bookkeeping around it, and everything one is ever asked to trust reduces to it.

Each click applies one rewrite. The session, however, is not mutating a string, as a text editor would: it is building a two-dimensional diagram, one swap cell pasted on at each step, and the word on screen is only the frontier of the construction. Stop at any point and switch the visualisation from the step view to the proof view: everything that has happened is there, as a single diagram.

It is worth pausing on that diagram. It is not a log of the computation; it is the computation, a first-class term of the language, which can be inspected, replayed, pasted into larger diagrams, and acted upon by higher-dimensional computations in its turn. If one only wants the answer, one asks for its output boundary.

Computational transparency

Recall the Curry–Howard correspondence, according to which programs are proofs: a well-typed term certifies, by existing, that the program it denotes is correctly formed. The correspondence, however, speaks only of the program. A term also carries an equational theory—a notion of when two terms are “the same”—and this theory, the very mechanism by which programs run, is meta-theoretical: assumed to exist, assumed to be computable, and in practice entrusted to the compiler. One may certify the program inside the language; to certify its execution, one must trust something outside it.

With diagrams, this boundary disappears. The rules by which a type computes are generators of the type itself, written down beside the ordinary ones, and a run of a program is a higher term—exactly the diagram built in the session above.

Well-typed terms are verified programs. Well-typed higher terms are verified executions.

I call this principle computational transparency, and it is alifib’s reason to exist. A verified program is not yet a verified run; between the two stands the whole tower of compilers and machines, and it is there that guarantees tend to evaporate. Our concern in this programme is with what a system did, rather than with what it was meant to do, and transparency is that concern made into syntax: the object one examines is the run itself, not a report of the run.

There is a consequence worth stating on its own. Since the rules by which a type computes are its own generators, each type is its own computational universe: its generators create, at the same time, the space in which computations happen, the data on which they act, and the computations themselves; nothing arrives from outside. A type expressive enough to house a Turing machine is still, in this sense, a sandbox, accounted for cell by cell by a kernel small enough to be read.

None of this is confined to two-letter alphabets. examples/TRS.ali sets up term rewriting systems in general, their terms two-dimensional diagrams and their runs three-dimensional ones, and examples/BinaryNat.ali instantiates it with binary arithmetic, so that

@BinaryNat
let d = (run auto on Eval.(run auto on parse "57 * (12 + 30)" end))

binds d not to the number 2394 but to a witness of the entire computation, whose output boundary is 2394. Since parsing, evaluation, and execution are all the same kind of diagram, parsing itself turns out to be functorial—the parse map sends parse traces of arithmetic expressions to the diagrams they denote—a remark that I will not develop here, beyond noting that those two files carry it out.

Eckmann–Hilton, by hand

Because equations are directed cells, equational reasoning in a higher-categorical structure is the same activity as running a machine. The classic Eckmann–Hilton argument says that two endomorphisms a, b of an identity must commute. In examples/EckmannHilton.ali the setting is built over a Bicategory module—itself written in ordinary alifib, its structural laws oriented into pairs of cells one dimension up—and the claim is stated as a map into the module’s type of equations, with two images withheld:

@EckmannHilton
let total Commutativity :: Equation = [
    lhs => a b,
    rhs => b a,
    dir => ?,
    inv => ?
]

Each ? is a hole: an image left open, to be filled interactively. The two fills are the proof: a pair of three-dimensional diagrams assembled by clicking through rewrites exactly as before, in which a and b slide past one another. Textbooks give this argument as a sequence of pictures, and the sequence built here is scarcely longer; the difference is that every move now exists as a cell, checked and retained, where the pictures rely on the reader’s goodwill to interpolate between them.

Four readings

Beneath the syntax, an alifib type is a finite directed complex: a finite family of cells graded by dimension, each carrying a partition of its boundary into an input half and an output half. The combinatorics—the molecules of my book, Combinatorics of higher-categorical diagrams—descend from far-sighted work of Richard Steiner in the early 1990s, in a lineage that runs back through Ross Street to the early days of higher category theory. What holds the construction together is topological soundness: every such complex is realised by an honest cell complex with exactly one cell per generator, so the combinatorics never drift from the geometry they claim to describe.

The reward is that one object may be read, faithfully, in four ways at once: as a piece of directed topology; as a presentation of a higher category; as a higher-dimensional rewrite system; and as a directed higher inductive type, with constructors between constructors. Each reading is a way of using the language—one may reason equationally in monoidal categories and bicategories, specify abstract machines whose every run is a witnessed trace, or describe a space and ask for its homology at the prompt—and the readings illuminate one another. In examples/Bicategory_examples.ali, the walking equivalence (a morphism invertible up to invertible 2-cells) sits beside the walking adjoint equivalence, which adds the two triangle equations of an adjunction. Asked for their homology, the interpreter reports $H_2 = \mathbb{Z}$ for the first and $H_2 = 0$ for the second: a hole in dimension two, witnessing topologically the classical fact that a bare equivalence is not coherent—and that promoting it to an adjoint equivalence is precisely what fills the hole.

What comes next

alifib today is a working system: a batch interpreter, a terminal REPL, the browser interface pictured throughout this post, a line-protocol daemon for editors, and an MCP server offering the same engine, tool by tool, to AI agents. The last deserves a word. In alifib, building a proof is search, and search is untrusted, whether a human is clicking or a model is calling; what is trusted is the kernel that accepts or rejects each step. It does not matter, then, how capable or how erratic the model is: nothing it produces enters a type except through the same check that governs a human hand. This division of labour—an inventive but untrusted proposer set against a small checker—will sound familiar to readers from the Safeguarded AI programme.

alifib can be tried at http://compose.ee/alifib, and its source lives at https://github.com/ahadziha/alifib. A paper giving a full account of the language and its interpreter is currently under review.

Further off, modules will acquire higher cells of their own (a module is already, in disguise, a complex whose points are types); a strategy language, where the effectful part of the runtime will live, I/O included, is being worked out with Wessel de Weijer; and a small family of type constructors—duals, suspensions, Gray products, joins—will make globes, oriented simplices, and oriented cubes available structurally, rather than as constructions made by hand.

There are many established mathematical languages for describing the world. Differential equations describe quantities that evolve continuously over time, such as temperature or motion. State machines and automata describe systems that move between discrete modes. Markov decision processes capture decision-making under uncertainty. Petri nets represent concurrency and competition for shared resources. Each of these formalisms help model different sorts of behaviours that we find in the real world.

Hybrid-system formalisms are designed to bring multiple of these lenses together. We are investing in Stochastic Dynamic Coloured Petri Nets (SDCPNs), a Petri net variant that provides a way to represent continuous and discrete behaviour, multiple interacting entities, structured state, data-dependent decisions, concurrency and randomness within a single framework.

That combination is particularly useful for cyber-physical systems: where a physical process is monitored and even controlled by digital elements. A physical change may enable or block a decision; a decision in cyberspace can alter a physical trajectory; and failures often emerge not from either side independently, but from their interaction.

In this post we’ll build up an SDCPN from an ordinary Petri net, explain what each extension adds, and then use several cyber-physical examples to show the range of systems the resulting formalism can represent.

What is an SDCPN?

A Petri net is a directed bipartite graph where places (circles) and transitions (rectangles) are connected by arcs (edges/arrows), in totality representing a process. Places can represent conditions or resource buckets and are marked by tokens, with the markings recording the state of the process at any given moment. Transitions are enabled by the presence of tokens in their input places, and when they fire they consume tokens from their input places and produce tokens in their output places, thereby changing the state of the process.

For example, a very simple Petri net modelling a pedestrian traffic light might look like this:

The above Petri net includes two places, Red and Green, connected by two transitions. The net starts with one token in Red, when “Switch to Green” fires, it moves to Green; when “Switch to Red” fires, it moves back to Red. This illustrates the logic of switching between green and red on a traffic light. In practice the firings would be near-instantaneous.

A plain Petri net records what can happen and in what order, but without modelling durations, likelihoods, or what distinguishes one token from another, and it cannot answer “how often” or “how likely” questions about a given scenario.

An SDCPN extends a plain Petri net with 4 features:

• Colour. Each place is associated with a colour set $C$, which defines the type and structure of data that tokens in that place may carry. A token residing in the place has a particular colouring $x \in C$: that is, a specific assignment of values to the attributes defined by the place’s colour set. Colouring therefore makes otherwise identical tokens distinguishable. For example, if a place represents stored food products, its colour set might specify the tuple (product ID, production date, expiry date, …), while an individual token could have colouring $x = (\text{P123}, 01/06/2026, 01/09/2026, \dots)$. Token values can be used to influence net behaviour, for example the introduction of a transition guard function $G(x)$, which evaluates the colouring $x$ of the tokens available to a transition. The transition is enabled when $G(x)=1$ and disabled when $G(x)=0$. For instance, a transition representing “ship to customer” could have a guard $G(x)$ = 1 if the product’s expiry_date > today + 365 days, and $G(x)$ = 0 otherwise, so that only products that have a sufficient shelf life are eligible for shipment.

• Stochastic firing. Rather than firing immediately once enabled, each enabled transition i independently draws a random firing delay from a probability distribution whose parameters can depend on the token’s colouring $x$. In the common exponential case, $P(\text{fire in } dt) \approx \lambda_i(x)\,dt$, where $\lambda_i$ is the firing rate of transition i. When multiple transitions are enabled, the one with the shortest sampled delay fires first. A higher $\lambda$ means a shorter expected delay, so faster processes tend to fire before slower ones, but a slower transition can still occasionally fire first. For example, the chance of a delivery van breaking down can depend on colour dimensions which record the van’s age and the length of time since its last maintenance.

• Deterministic dynamics (ordinary differential equations - ODEs). While a token sits in a place, its colouring $x$ (e.g. fluid level, machine’s wear) evolves continuously through

  $$dx = f(x, p)\,dt$$

  where $f(x, p)$ is the deterministic drift term which dictates the trend of the colouring evolution and $p$ is the set of fixed constants such as flow rates or degradation coefficients. This evolution replaces the assumption of static token colouring: a token’s data changes continuously while it remains in a place, according to differential equations that can represent processes such as material consumption, fluid-level changes, or progressive equipment degradation. Whether a token enables a transition or at what rate the enabled transition will fire can therefore evolve over time depending on the evolution of token data. We can use this to model the freshness of food decreasing over time at a rate of $dx = -k e^{-T/20}\,dt$, where $k$ is a base decay rate and $T$ is the storage temperature, so warmer conditions accelerate the loss of freshness and the product becomes unsellable when its freshness crosses a threshold.

• Stochastic dynamics (stochastic differential equations - SDEs). The differential equations can include random noise, so continuous evolution can be perturbed by random noise. This is represented as a stochastic differential equation (SDE):

  $$dx = f(x, p)\,dt + \sigma(x, p)\,dB$$

  where $B$ denotes a stochastic process such as the Wiener process through which randomness enters and $\sigma(x, p)$ is the diffusion term acting as the scaling factor of randomness. The first term $f(x, p)$ is the same drift term appearing in deterministic dynamics. Examples of stochastic dynamics are demand rates or ambient temperature drifting randomly.

The four features together allow SDCPNs to represent all aspects of a cyber-physical system in the same state and clock: its physical process (a tank emptying, a machine wearing), control logic (when to dispatch, when to service), and the randomness that affects both (a breakdown, a demand spike).

The origin of SDCPNs

While ordinary Petri nets date back to the 1960s, SDCPNs were developed by Mariken Everdij and Henk Blom at the National Aerospace Laboratory (NLR) in the Netherlands, in the early 2000s. The problem they were trying to solve was quantifying the probability of a mid-air collision, an event too rare to observe in testing, and requires modelling many aircraft moving continuously, controlled by different humans and automated systems. Everdij and Blom extended the Dynamically Coloured Petri Net (DCPN) by adding Brownian motion to the equations governing how token data evolves between firings, and defined the result as a formal 12-component specification (P, T, A, N, S, C, V, W, G, D, F, I).

The formalism was designed to support a safety case, expressed in probabilistic terms: a defensible and quantitative statement about how often something bad happens in a system too complex to test exhaustively. With a view to enabling the same kind of guarantees to be made regarding the behaviour of frontier AI models, the ARIA Safeguarded AI (SgAI) programme is also building on SDCPNs. Our goal is to enable the development of world models expressive enough to represent both complex physical systems and the AI that control them, with a safety specification over both. The air traffic problem, with continuous dynamics, multiple agents, human and automated controllers, rare catastrophic events is exactly the class of system SgAI is building for. The only difference is the controller: the original use case modelled human operators and procedural automation, while SgAI focuses on neural networks.

Modelling the real world with SDCPNs

The three sections that follow model real systems as SDCPNs. The first, an industrial gas supply chain, is built progressively: one feature of the formalism is added at each step until the model is a full SDCPN. The other two, truck fleet maintenance and semiconductor fabrication, are described as full SDCPNs from the start, to illustrate the range of domains the formalism reaches.

Industrial gas supply chain

Taking an industrial gases supply chain as an example use case: a gas supplier delivers liquid gases (e.g. nitrogen, oxygen) to customer sites by road tankers. The supply chain operates in a standard practice where the supplier owns the liquid in each customer’s tank, reads the level by telemetry, and decides when to send a refill. The customer draws product as needed and only pays for what they consume, but does not place orders.

Each tank empties from two sources: the customer’s consumption and heat leaking through the walls, which boils liquid gas off continuously. A delivery that arrives before enough space exists risks overfilling. The supplier must keep every tank within a safe range:

• Too low: the customer’s production line stops (stockout).

• Too full: boil-off gas has nowhere to go, pressure rises, and the relief valve vents the gases into the atmosphere, creating wastage and potential safety concerns.

The reorder point, load size, consumption rate, boil-off rate, and delivery lead time are all coupled. A tanker dispatched to one site is unavailable to other customer sites until it returns.

Plain Petri net

First we model the system using a plain Petri net with only places, transitions, tokens (without colours) and different arcs and arc weights.

The net consists of just 1 customer site to illustrate the core concepts. To start, there is a tank of nitrogen on site holding 42 out of 54 units of liquid gas; one tanker at the depot and up to 2 loads may be on order at once. The customer’s production line is running.

As the customer consumes the nitrogen and some boils off, the level drops. When the level drops to 15 (representing the telemetry-based sensor in the tank), an order is placed. A tanker dispatches, arrives and delivers 12 units (only if 12 units of space exist in the tank). The permit and tanker return on delivery and cycle repeats.

Stockout happens if the tank hits zero and the production line stops. It restarts when at least 1 unit arrives.

If the tank is completely full, a relief valve opens and reduces the level of gas (by 1 unit). Under this level trigger order policy, venting is unreachable since the maths of the reorder point and load size prevent it (gas only refills by 12 units when at or below 15 units). In later timed-extensions of the model, we introduce pressure-driven venting since in practice, venting is required when pressure gradually builds as the liquid warms.

The above shows the net for a variant of the order policy based on consumption-trigger. Instead of reordering when the level drops below a threshold, the system reorders after every 8 units are drawn by the customer without accounting for any evaporation. This results in a failure mode whereby, If enough nitrogen boils off, the tank empties without the consumption counter ever reaching 8. The system reaches a deadlock: the tank is at zero, fewer than 8 units have been drawn since the last order, and nothing in the model can change the state in the system so the production line stops and never restarts.

Without time accounted for in the model, the net picks any enabled transition to fire without any rules on ordering. There can be a scenario where the transition for consuming nitrogen is fired repeatedly and empties the contents without dispatching the tanker for refill. Adding durations fixes this so events happen according to rates rather than random choice, which we explore in the next progression where stochastic firing rates are added.

This basic Petri net is useful for checking the logic of the system, such as finding deadlocks (consumption-trigger variant), checking conservation laws (liquid + ullage = 54 always) etc. Without the additional features, it falls short on answering the more interesting timing questions like whether the tank runs dry before the tanker arrives, or what load size and reorder point minimise stockouts.

Add time

The above shows a Stochastic Petri net (SPN), based on the same structure as the basic Petri net with the addition of rates on each transition and a second site (SlowNitrogen) to represent a low-consumption customer.

Each enabled transition now independently draws a random delay time from a general family of distributions. One prominent distribution in this family is the exponential distribution, where each transition has a random delay $t \in (0, \infty)$ drawn from:

where $\lambda$ is the average delay per hour (firing rate) for that transition. So whichever transition is delayed the least fires first. For example, when the customer’s (SteadyNitrogen) tank is half full, three transitions are enabled at once: the customer drawing product (rate 0.80/h), boil-off (0.16/h), and the tanker arriving (rate 1/6 ≈ 0.17/h). The runtime engine rolls a random delay time for each: 0.45 hours for product draw, 3.1 hours for boil-off, and 2.8 hours for the arrival. The nitrogen draw transition fires first so one unit leaves the tank, the clock advances 0.45 hours, and all three roll again from scratch.

A limitation of modelling journey time as a stochastic rate on the arrival transition (1/6 or 1/9 per hour, giving mean journeys of 6 and 9 hours) is that the exponential distribution allows a delivery to arrive almost immediately or take far longer than its mean. Realistic journey times need a minimum and a bounded spread, which requires clocks counted down by dynamics.

With the addition of a second customer, the one supplier tanker serves both sites with a new “returning” state to represent the time the tanker spends driving home after each delivery, introducing a risk of stockout if one customer is left waiting whilst the tanker delivers for another. For example, if the SteadyNitrogen tank crosses its reorder threshold (16 units) while the tanker is mid-journey to the SlowNitrogen site, it must wait for the delivery to complete (up to 9 hours remaining), the return trip (~4 hours) plus its own journey (~6 hours) before receiving the product. At a combined drain of ~0.96 units/hour, 16 units of buffer lasts roughly 17 hours, so on some runs can result in a stockout for the high consumption customer (SteadyNitrogen).

This stochastic net introduces time and contention with transitions competing to fire next and additional customers that can lock out delivery for each other. It answers questions on stockout frequency, the cost of sharing a tanker and the effect of slower routes. It falls short on the realism of timing (a 6-hour journey is exponentially distributed, so it sometimes arrives in minutes and sometimes takes a day), distinguishing between different products, and continuous processes like boil-off are still modelled as discrete random events rather than a steady flow.

Add data types (colours)

To distinguish which product a tanker is holding, we can add colours so each tanker token now has a data field identifying its gas type. In this example, the timing mechanism stays stochastic but the network grows to three customers and three tankers.

The third customer requires a different type of gas, oxygen with a draw rate of 0.60/h and average delivery journey time of 12 hours. The depot now holds 3 tankers (2 nitrogen, 1 oxygen) and a transition guard checks the correct product is dispatched. If a nitrogen order is placed and only the oxygen tanker is idle, the order waits. The cycle for drawing, boiling-off and ordering works as before.

With product identity added to the fleet, the SPN with colours can answer questions on whether fleet composition matters more than fleet count and by how much. For example, the same three tankers re-specified from one to two oxygen tankers can eliminate the oxygen stockout completely if they are the most critical customer from a business perspective. The colour features also allows for modelling of tanker spot hires. For example if 3 or more orders are waiting and no tanker is idle, a hire transition fires: its kernel writes a new tanker token into the depot with a rental flag, and a release transition destroys it when the demand clears. (This is included in the next progression where the colours are evolving (dynamics).)

This model still has the same timing limitations as the SPN: exponential journey times and discrete boil-off events.

Add continuous evolution

This model adds dynamic colours and replaces the stack of unit tokens with a single token governed by differential equations, to model the level of gas and pressure as real numbers that can fall or grow continuously. With the inclusion of dynamics, the net can now model scenarios that simpler nets couldn’t:

• Pressure building in a tank with relief valve cycling. Boil-off gas fills the empty space above the liquid, the reduced space raises the pressure more so a fuller tank pressurises faster. When pressure reaches the relief setpoint (8 units), the valve opens, 0.4 units of liquid escape as gas and the pressure drops just below 8. If the tank is still nearly full, pressure climbs back to 8 and the valve opens again. This reveals a trade-off where a fuller tank means fewer stockouts but more wastage through vented product, resulting in higher supplier costs.

• Realistic durations from lognormal distributions. The dispatch kernel samples a journey time from a lognormal distribution and writes it onto the tanker token. Place dynamics counts the remaining time down by 1 per hour, and the arrival transition fires when it reaches 0. This gives each journey a reasonable minimum, a mode near the nominal hours, and a long tail for delays.

To add further realism, the net models outages in supplier’s own liquid production as discrete events. The production plant can experience an outage, on average every 90 hours (frequency exaggerated for visibility in simulation) and takes 24 hours to restart. While it is down, deliveries are dispatched from a more distant plant and increases each journey time by almost double.

This model captures the physical behaviour that the simpler nets cannot: tanks drain smoothly, pressure builds and vents in cycles, and journey times have realistic distributions rather than memoryless exponentials. What it does not capture is variability in the environment: customers always draw products at a constant contracted rate, and pressure boil-off does not vary with temperature.

Truck fleet maintenance

SDCPNs can be used for truck fleet operators to solve their maintenance problem, in deciding when and where they should service each vehicle. The service must occur early enough to prevent a breakdown on the road, and late enough not to waste maintenance capacity. The maintenance schedule must ensure deliveries are still completed within the agreed window.

In this example, the fleet operator has 8 trucks over three route classes: motorway (420 km, flat), urban (180 km, stop-start), and mountain (260 km, steep gradients). Loads are posted to a freight board at stochastic rates; if no truck collects one within 10 hours, it goes to a competitor. Each delivery has a time window (2.2× driving time): missing the window incurs a 30% revenue penalty, missing it entirely (breakdown mid-route) means losing the load and paying for recovery.

The depot has 2 service bays, 2 technicians, and a stock of spare parts. A truck that reaches a wear threshold is serviced (5 hours, resets to new). A truck that breaks down at the roadside needs a recovery vehicle, a tow, and a longer repair (12 hours, only partially restores condition). Both compete for the same bays, technicians, and parts.

Each truck is modelled as a coloured token carrying 19 fields of continuous and discrete colouring. The key mechanisms are:

• Evolution of three wear components per truck governed by deterministic dynamics. Brakes, engine, and tyres each degrade at different rates depending on the route. Brake wear accumulates 2.5× faster on mountain descents (heavy braking on gradients); engine wear increases when carrying load; tyre wear rises with road roughness and weather severity.

• Breakdown as stochastic firing driven by the weakest component. The roadside failure rate is set by whichever component is the most degraded. As degradation increases, the firing rate $\lambda$ increases, so a truck with fresh brakes and fresh tyres but a worn engine fails at the engine’s rate.

• Road condition evolution governed by stochastic dynamics. The same diffusion mechanism that models ambient temperature in the industrial gas supply chain is also used here to model the variations in driving conditions that a truck encounters on any given trip. Two state variables on each truck token represent this road conditions: road severity which multiplies all wear rates and fuel consumption and speed factor which impacts travel speed and therefore journey time.

• Driver hours enforced through colour and guard. Each truck token carries a running hours field, and a guard that prevents dispatch once it exceeds the legal limit. EU Regulation (561/2006) limits drivers to 9 hours of continuous driving, so the model includes a compulsory rest stop at the depot for 11 hours before it can be dispatched again.

The model helps the operator understand the interactions between servicing policy, workshop capacity and dispatch rules in relation to fleet profitability whilst accounting for variability in weather and roads. The main simplification is that it models one depot with identical trucks and generic parts. A real operator has multiple depots, mixed-age vehicles, component-specific spares, and demand that varies with season.

Semiconductor wafer fabrication

A semiconductor foundry processes batches of wafers (wafer lots) through 28 steps using shared machines. The same machine group handles multiple steps in the sequence, for example the same lithography group is visited at layers 0, 4, 9, 12, 16, 20, and 24, so wafer lots at different stages compete for the same machines.

The main trade-off is between throughput and yield. Machines degrade as they work, but taking one offline for maintenance backs up the production. Deferring maintenance increases the risk for breakdown or slow accumulation of defects that only becomes visible at final inspection.

For this use case we modelled 16 chambers across 4 machine groups (4 lithography, 6 etch, 4 furnace, 2 inspection), 3 product types (logic, memory, analog) arriving stochastically, a capacity limit of 50 lots in progress, and 3 technicians shared between planned and unplanned work.

Each lot token carries its product type, current layer, cumulative defects, age, and a customer due date. Each machine token holds data on its condition, particle count, hours since maintenance, machine group, qualification level, and batch counter. The degradation mechanisms use the following SDCPN features:

• Machine degradation is modelled as deterministic dynamics that accelerate with contamination. When the machine crosses a threshold (default 0.85) it triggers preventive maintenance. The breakdown rate grows exponentially with condition, so a machine at 0.9 fails 8 times faster than a fresh one.

• Microscopic particle contamination as stochastic dynamics. Contamination fluctuates randomly but trends upward the longer a machine runs without maintenance.

• Per-chamber process drift as stochastic dynamics. Each chamber’s process accuracy varies independently via a second diffusion process. Drift in either direction from zero increases defect rates. Maintenance recalibrates the chamber, but calibration is imperfect and each reset samples a small residual error. This means two chambers on the same tool can produce different defect rates even at identical condition and particle levels.

• Defects at each step are sampled from a distribution when the processing transition fires. The mean depends on the machine’s current condition, its particle count and process drift. A clean, well-calibrated chamber deposits few defects; a degraded, contaminated or drifted chamber deposits many. Defects accumulate across all 28 layers but the number of defects is only checked at final inspection.

To model the dispatch mechanism as close to real-world fabrication as possible, the net enforces all four of the below constraints simultaneously:

• Machine-specific qualification. Not every machine can run every product. Each machine carries a bitmask encoding which product types it is certified for.

• Chamber-level recipes. Processing time depends on the product being made. For example, a furnace step takes 5 hours at baseline; analog lots take 15% longer, memory lots 15% shorter. The same applies to lithography and etch steps.

• Batch processing for furnaces. Furnace steps require loading multiple lots before the chamber fires. Lots destined for a furnace layer enter a batch queue and are loaded one at a time into an available furnace chamber. In the model the furnace only starts when the batch reaches 4 lots, or after 3 hours if fewer are available.

• Dynamic priority from customer due dates. Each lot arrives with a due date. Between dispatch events, the lot’s priority escalates continuously via dynamics. Priority is recalculated every 2 hours based on remaining time to deadline. A lot close to its due date is dispatched ahead of a lot with time in hand. Lots that exceed their due date by 30 hours trigger a deadline renegotiation, and the due date extends by one full cycle time and priority resets, representing the real-world practice of agreeing a new delivery window with the customer.

The model can help fabrication managers understand the interaction between maintenance policy, chamber calibration, batch sizing and in progress capacity in relation to yield and on-time delivery. The main simplifications are that each chamber processes one lot at a time and lots cannot be split for partial rework (lot-splitting). This means the model’s absolute throughput figures are lower than a real foundry’s, but relative comparisons between scenarios remain valid because all scenarios share the same simplification. Modelling lot-splitting would reduce the cost of contamination events by allowing partial recovery as a secondary effect, but does not change the fundamental question of when to maintain.

Beyond simulation: guarantees and probabilistic claims

Running a simulation shows what’s expected to happen under a specific set of conditions. However, simulations don’t show what happens under untested conditions, nor is it guaranteed that simulations which are run are in any way representative of the real world. This section covers two kinds of claims that go beyond individual runs: structural guarantees that follow from the net’s topology alone, and probabilistic claims built on sampling. Other parts of the SgAI programme are developing methods for reasoning formally about complex, compositional SDCPN models at scale; here we focus on what the net structure and simulation-based methods already provide.

Structural guarantees

These come from the net’s topology, arc weights and connections:

• Reachability. Can the system ever reach a specific state? For example: “is there any sequence of events that results in the tank being empty with no order on its way?” The check works by building the full graph of every state the net can reach from its starting state by firing every enabled transition and recording each new state. If the target state appears in that graph, it is reachable. If it does not appear, it is proven unreachable from the given starting state regardless of timing or ordering.

• Coverability. Reachability asks whether the net can reach a specified marking: the exact number and types of tokens in every place. Coverability asks whether the net can reach a marking that contains at least what you specify, while allowing additional tokens in any place. For example it answers the question, “Can there be at least 10 failed machines?", without specifying token counts for the other places.

• Boundedness. For any place in the net, you can determine the highest number of tokens it can ever hold by scanning every state in the full state graph and recording the maximum token count seen at each place. If the graph is finite, that maximum is the proven bound and can never be exceeded in any execution. If the graph cannot be completed (because some place grows without limit), the net is unbounded at that place, which usually signals a modelling error or a missing constraint. Conservation is a special case, where if a set of places always sums to the same total (e.g. items in storage + items in transit = total inventory), then each place in that set is bounded.

• Liveness. Can every transition fire at least once? A transition that never appears in the state graph is dead, either from a modelling error or a mechanism that is unreachable by design. Deadlock is the extreme case: no transition can fire and the system freezes.

These checks require a finite state space. Once tokens carry real-valued data (continuous levels, pressures, temperatures), the state graph cannot be exhaustively checked and these proofs do not apply directly. Extending formal guarantees to models with continuous state and stochastic dynamics is an open research problem, and one of the reasons the ARIA Safeguarded AI programme is investing in this formalism.

Probabilistic claims

Once the model includes randomness, it produces distributions rather than single answers. An SDCPN produces probabilistic results differently from a conventional simulator in two ways:

• The randomness is formal and inspectable. Firing rates, lognormal durations, diffusion terms etc. are explicit components of the model specification. They can be inspected so a reviewer can read exactly what distribution governs each event. In a conventional simulator, stochastic behaviour typically lives in code scattered across event handlers.

• Rare-event probabilities can be quantified. Some failures are too rare to observe in ordinary Monte Carlo, estimating a probability of $10^{-9}$ would need billions of runs. SDCPNs support acceleration methods (importance sampling, interacting particle systems) that exploit the net’s structure (strong Markov property) to estimate these probabilities efficiently.

Tooling for scalable oversight

HASH leads the “Interaction Paradigms” technical area (TA1.3) of the SgAI programme. As part of this work, we’ve developed tooling to enable not only the modelling and simulation of complex systems as SDCPNs, but also AI that assists users in capturing their understanding of a domain while ensuring information relevant to a model or experiment isn’t missed or misrepresented. The same AI is also usable to help users understand complicated models developed by other people (or AI), and enables the precision editing, customisation, and hierarchical use of existing models. This open-source tooling is available at petrinaut.org, as well as integrated into HASH’s semantic graph platform (app.hash.ai). All of the interactive examples embedded in this post were built and run from the Petrinaut demo website.

Conclusion

As we’ve shown in this post, SDCPNs can be applied to virtually any cyber-physical domain: from industrial gas supply and truck fleet maintenance through to semiconductor fabrication, and the other use-cases we’re exploring as part of SgAI — with our own work predominantly focused on biopharmaceutical and chemicals manufacturing and logistics.

Each feature from the SDCPN formalism adds something new:

• A plain Petri net finds logical and structural failures like deadlocks

• Stochastic firing adds timing, so the model can quantify how often events like stockouts occur.

• Colour makes identity visible so fleet composition or product routing can be modelled.

• Continuous dynamics replace discrete approximations with differential equations for flows like gas levels, machine degradation and contamination.

• Stochastic dynamics helps to add the necessary real world noise, like environmental variability to the model.

Not only can SDCPNs represent these various interactions, but it can quantify the frequency, costs and conditions that trigger them, too. This kind of quantification is what will enable us to move away from a world of weak evals and assumptions to one in which AI can be used as a real-time decision maker in safety-critical, cyber-physical systems, backed by evidence and verification.

Frames and formal models today

A wide swathe of technical creative activity, from creating scientific models and engineering designs to writing computer programs to making spreadsheets, is aimed at expressing a model of something precisely enough to be operationalized on a computer. The model, or at least the part of it given algorithmic content, is thus in principle mathematizable. We will think of scientific models, engineering designs, computer programs, and spreadsheets all as kinds of formal models, even if the degree to which they are formalized mathematically varies in the current state of practice.

Any formal model exists within some frame,¹ defining the concepts and language within which the model is expressed and the rules to which this expression must conform. A typical frame for scientific modeling might be “a parameterized system of ordinary differential equations,” specific enough to unambiguously describe a class of models and to support uniform algorithms for fitting and simulation. The frame for a computer program is, to a first approximation, the programming language in which it’s written along with the ecosystem of libraries supporting it.

Frames can be more or less constrained. A relatively unconstrained frame has the obvious benefit of allowing creator flexibility to formally express their intent. A relatively constrained frame carries a more definite and opinionated viewpoint, stipulating stronger structure and assumptions. This makes it easier to say some things, while prohibiting the expression of other things. This is good to the extent that it blocks expressions that would be outright mistakes or, more subtly, would deviate from settled design decisions or conventions. Of course, it is bad to the extent that it prevents useful and desirable expressions not anticipated by the choice of frame.

Builders and users of computing technology seem to have revealed an overwhelming preference for unconstrained frames. From the beginning, the field of computing has, in its theory, emphasized the universality of programming languages; in its practice, language designers herald something more elusive, the “expressivity” of their languages. Meanwhile, the species of mathematized software most widely used by people who are not mathematicians or programmers—the spreadsheet—is highly unconstrained, a blank canvas for tabular data with no further requirements on data layout or typing. Advanced users can introduce their own logic, of arbitrary complexity, within cell formulas, which can vary across cells in arbitrary ways.

It is not hard to imagine what might lie behind this preference for unconstrained frames. Working in a constrained frame, if a creator reaches the boundary of the frame, they may be unable to express their intent at all within the formal model, an experience at best frustrating and at worst intolerable. In the most unconstrained frames, like a general-purpose programming language, it is usually possible to find some way to proceed, even if it involves blurring or subverting what were once crisp abstractions. Put simply, most people would rather muddle through than risk hitting an immovable wall.

Nevertheless, the costs borne under the status quo are severe, and growing. With the frame for the formal model having few hard constraints, the typical software project of even moderate complexity relies on a web of semi-formal and informal abstractions described by a mix of code and documentation but not fully specified by either. Rather, the abstractions are maintained—if they are maintained—by a shared understanding among the engineering team, created and renewed through careful communication. Competent programmers create bugs not by trivial logic errors but by failing to understand intricacies of what software abstractions assume or how they interact with each other.

As for spreadsheets, a notorious weakness of the spreadsheet frame is in transitioning from individual use to reliable organizational processes. Because the assumptions behind a spreadsheet are highly implicit, hidden within a web of cell dependencies and in the mind of the spreadsheet’s designer, it is all too easy to make ad hoc changes that silently break those assumptions. The lack of type constraints in spreadsheets is a frequent source of errors, including the perennial joke that Excel interprets every input it sees as a date. While different in many respects, what unites the standard paradigms for programming and spreadsheets is that by situating the formal model in a generic and unconstrained frame, the domain-specific abstractions that inevitably support the model possess little formal content; to compensate, disciplined human processes are required to safely use and change the model at any scale beyond a single person.

The effect of emerging LLM technology

Such is the status quo, an equilibrium beset by familiar problems but so far ultimately workable. New technology, in the form of generative machine learning based on LLMs, threatens the status quo by changing the tradeoffs involved. It also presents an opportunity to rethink how we design technologies for formal modeling.

In programming, the emergence of LLMs is decreasing the cost of generating more or less functional code, while exacerbating the challenge of maintaining a coherent set of abstractions and assumptions. The experienced programmer, when attempting to make a change, will notice when the change seems to depart from existing structures or assumptions and take the opportunity to rethink their approach, which can ultimately lead to revising past design decisions or changing the abstractions. The LLM, ever compliant, proceeds blithely along the path of least resistance. Moreover, while adept at mirroring surface-level patterns present in the codebase, the LLM is not privy to the web of shared mental representations that enable the effective engineering team to function.² Thus, at present, LLM coding agents appear to enable significant short-term productivity gains while gradually reducing the codebase’s overall concision and coherence. As LLMs become more prolific in office work, the lack of explicit structure and typing constraints in tools like spreadsheets will only exacerbate the fragility already present. In both cases, the distinction between creating, an active process that engages the mind and forces it to confront problems, and reviewing, a passive activity often experienced as boring, means that opportunities to catch mistakes or revisit assumptions are more likely to be missed when LLMs are heavily involved.

It has been suggested that the solution to this problem is that humans cease to interact directly with formal models at all. A formal model is useful, the thought goes, only insofar as it fulfills some externally validatable purpose; if it does so adequately, it does not matter how the model was constructed or how messy it might be internally. The LLM will mediate the interaction between the human and the formal model exclusively through natural language, so that the human never has to look inside.

Whether or not it is technically feasible, this vision misses much of the point of using formal models in the first place. Be they scientific models or computer programs or spreadsheets or abstract philosophical schemes, mathematical (or at least mathematizable) models have been among humanity’s most successful tools to augment our capacity for thinking. Not only does having good formal models increase our powers of deduction, prediction, and counterfactual reasoning, but the process of creating models forces us to sharpen and clarify our ideas, both for ourselves and to communicate with others. To abdicate a direct role in formal modeling would be to weaken human capability and agency.

The question then is not whether we should continue to directly interact with formal models but how the process of model building should adapt to a potent new source of automation and augmentation.

The future of formal modeling

All of the foregoing points to the same conclusion: that safe and reliable formal modeling pairing humans with LLM agents requires more constrained frames than are common today. Under our meaning of “frame,” this entails more than a Markdown file making vague suggestions; a frame specifies concepts, language, and assumptions that set the rules for formal modeling and are enforced when type checking a putative model.

How can we adopt more constrained frames while retaining the flexibility that has made the present paradigm of unconstrained modeling dominant? The question may seem paradoxical but the answer is, in a sense, simple: by insisting on more constrained frames, while making it possible to change the frame when needed.

It is easier to make this assertion than to say how it can be realized. Existing languages and tools that serve as frames for formal models tend to be very rigid. Changing them is costly and impractical. There are two reasons to believe that now is the right time to build more malleable tools for formal modeling.

First, as we have seen, LLMs have made it cheaper to generate code and other formal artifacts; consequently, they have made precise specification both more useful as input and more necessary to prevent abstraction drift. There is a growing recognition that existing practices must change. This recognition should create the will to explore new paradigms rather than tinker around the margins of existing ones.

Second, there is now a mature enough body of theoretical knowledge to actually create the new infrastructure that will allow fluidly defining and changing frames. This body of knowledge is broadly categorical logic, the intersection of category theory with mathematical logic and type theory. The role of logic and type theory as the mathematical underpinning for syntax in formal modeling is well known, and the use of categories as a denotational semantics for programming languages is familiar to experts. What is less appreciated, even among experts, is how category theory provides a meta-mathematical toolbox to enable modularity and reuse within and between frames, both in the narrow technical sense and in a more nebulous cultural sense affecting how we design formal languages. As we have noted, language designers have overwhelmingly sought to create ever more general and expressive languages, the ideal frame in which to say everything that can be said. This attitude is essentially reductionist. Category theory encourages us to see logic not as something prior to mathematics and science, but as a part of it, and to search for well-adapted mathematical universes in which to create models.³ These universes can look familiar, like functional programming or first-order logic, but can also natively encompass non-standard features crucial in certain domains, such as resource sensitivity, reversibility, nondeterminism, probability, and fallibility. Categorical logic offers a uniform technical toolbox to describe these paradigms without privileging any of them.

In the CatColab project, supported by the ARIA Safeguarded AI program, we are exploring this vision for scientific and cyberphysical modeling, programming in domain-specific logics, and tabular and relational data. It is beyond the scope of this post to describe these efforts in detail, nor do we claim to have a complete account of any of these vast topics. Rather, in the remainder of this post, we will hone in on one of the paradigms highlighted above—spreadsheet-like data modeling—as a case study in how to build tools, underpinned by categorical logic, that set constrained frames for formal modeling while also allowing the frame to be changed fluidly.

Case study: Structuring spreadsheets

Among the most successful species of software ever created, the spreadsheet enables people who might otherwise never encounter formal models to interactively build their own. It is also a notorious source of ill-specified, unreliable processes. Instead of taking the spreadsheet to exist within a fixed, unconstrained frame,⁴ we envision a spreadsheet-like tool that allows creating and transforming not just data itself but frames that constrain the data.

This idea has an obvious precedent: the relational database, another very successful type of software. Using a relational database, the modeler defines a frame via a schema. In the most common incarnation of a relational database as a SQL database, a schema specifies types of entities (tables) with data attributes (columns), as well as functional relations (foreign keys) between entity types. Once a schema is defined, the database checks that the instance of the schema, given by actual tables of data, conforms to the schema, raising an error if a transaction would violate the constraints. It is a testament to their utility and soundness that SQL databases have enjoyed such a long lifespan, in essentially the same form, when so many other computing technologies have endlessly churned.

While SQL databases are, from a strictly logical standpoint, more powerful than spreadsheets, the two kinds of tool have little overlap in users and usage. There are more and less deep reasons for this. Certainly, SQL databases are harder to use than spreadsheets. Users of SQL databases, mostly programmers, interact with the database using the SQL language, a domain-specific formal language, while spreadsheets provide an intuitive graphical interface based on direct manipulation. This is practically important, and in our work on structured spreadsheets, we aim to create interfaces that allow and encourage direct manipulation. But the more basic reason that SQL databases are not a substitute for spreadsheets is that SQL databases are rigid where spreadsheets are fluid. SQL provides powerful languages to define schemas and query instances, but a far more limited language to change schemas. Database migrations usually comprise an ad hoc mix of SQL statements and generic code in an orchestrating programming language, and are a frequent source of frustration even for professional engineers. In short, SQL databases make it easy to define a frame but hard to change the frame.

Such situations are typical across science and engineering: experts know well their objects of study and often devise sophisticated formalisms for them, but tend to undertheorize the relations between objects.⁵ Category theory encourages us to take relations seriously by not introducing a class of objects without also considering the morphisms between them. In the case of relational databases, formulating a category-theoretic account of schemas leads directly to a plethora of notions of morphism between schemas. A morphism between schemas, defined declaratively, then induces a data migration between instances over those schemas.⁶

The vignettes that follow illustrate how constrained yet fluid modeling with tabular data enables more reliable automation with LLM agents. We will not enter into technical details about the underlying mathematics and technology, which is being actively developed. Rather, the aim is to convey a sense of what is possible through concrete examples backed by working demonstrations.

Inferring an initial frame

Relational data is often artificially flattened into a smaller number of tables or even a single table, in deference to the dominant abstraction in data science, the data frame. As a typical example, consider the DB1B dataset, a random sample of flight itineraries from reporting carriers, published quarterly as a set of three CSV files by the U.S. Bureau of Transportation Statistics. The intended schema for the data is conveniently summarized by a third-party note about airline industry datasets.

The three tables correspond to three types of entities, all related to itineraries: “tickets” (Ticket), covering the whole itinerary; “markets” (Market), covering a single direction of a ticket; and “coupons” (Coupon), covering individual flights.⁷ The entity types are linked by three mappings (foreign keys), as expressed by the diagram:

In addition, each of the entity types has a couple dozen data attributes.

We could prompt the LLM generically to “infer an appropriate schema for the data, then import the data” and hope for the best. That may well produce a decent result, but what would we learn from it? Instead, we pursue a more incremental and interactive strategy, starting with the loose frame advertised directly by the source material, then gradually building our understanding of the data and reifying that understanding by tightening the frame.

So we instead ask the LLM to “create a schema for the data capturing the stated foreign key relations and including all other columns as string-valued data attributes”. Since the columns in CSV files are untyped, the latter stipulation is safest for an initial frame. The result is the schema shown in the diagram above, augmented with many data attributes of type String (not shown).

We then ask the LLM to import the data itself as an instance of the schema. Even under our minimalist frame, it is already possible that the data could fail to conform to the schema by having links to entities that don’t exist. Since this data was presumably exported from a relational database enforcing foreign key constraints, we don’t expect this to happen, but it could still happen if, for example, the random sampling was not consistent with the relational structure. In any case, once the data is imported, the validity of the links will be automatically checked—not by the LLM, but by the type checker for instances, which is perfectly reliable—and any errant rows will be marked and reported.

Tightening the frame

Having set an initial frame and imported the data, we strengthen our understanding of the implicit model by attempting to add more constraints to the frame.

First of all, while it may not be obvious from the nomenclature, the entity types—Coupon, Market, and Ticket—form a hierarchy. Each ticket contains some number of markets, and each market contains some number of coupons. This means that, for each coupon, the ticket to which the coupon is attached should be equal to the coupon’s market’s ticket. We can state this logical requirement as a diagram (“the triangle commutes”):

Equivalently, as an equation in textual syntax:

When we add this path equation to the schema, the type checker will confirm that it is true of the instance. Assuming it is, we can keep the equation as a constraint that should apply to any future data. Better, though, is to observe that the equation makes the ItinID column of Coupon logically redundant, since it can always be computed by following the links through Market to Ticket. So we can save on physical storage by deleting the ItinID column of Coupon entirely. There is no disadvantage to doing so, since we can reintroduce it as a definition

that will be computed on demand and updated automatically when the data changes. In a spreadsheet, such a definition is called a formula; in a relational database, a view.

Redundancies can also be found in the data attributes. One such constraint is helpfully if informally noted in the third-party summary (footnote 1):

Carriers report complete itineraries so this [reporting carrier code] should be equal for all markets and coupons in an itinerary.

Or, formally:

Experiments show that LLMs are adept at identifying plausible constraints, a useful complement to human inspection. Many, but not all, of the proposed constraints validate against the data, and some are more complex than path equations, involving aggregations or injectivity/surjectivity constraints. For example, every ticket has at least one market, and every market has at least one coupon. These are surjectivity constraints, denoted graphically by double-headed arrows:

Another important vector for tightening the frame is to set stronger types on the data attributes, rather than making them all strings. Some attributes should plainly be (positive) integers (Year, Quarter), (nonnegative) real numbers (Distance, MilesFlown), or booleans (RoundTrip, BulkFare). In this data, booleans are encoded as indicator variables (0 or 1), requiring a modest amount of common sense on the part of the human or LLM to distinguish them from integers. In all cases the type conversions are automatically checked against the instance data and any type errors are reported.

Changing the frame

So far, we have reified and tested hypotheses about the model by introducing types and constraints and eliminating redundant data, while keeping intact the basic entity-relation structure of the original semi-formal schema. We may wish to alter the frame more drastically.

Inspecting the current schema, the experienced modeler of relational data will be struck that, in each table, the origin and destination airports are represented not by a single column (Origin or Dest), but additionally by many attributes of the airport (e.g. OriginCityNum, OriginCountry, OriginState). This flattening of the same relational data across many tables is messy, inefficient, and error-prone. Good modeling practice suggests that we should reify the airports as a new type of entity (Airport) with data attributes of its own.

With a little common sense, this should be a straightforward if tedious job, so we instruct the LLM to “refactor the schema by creating an Airport entity type with its own data attributes and factoring all information about origin/destination airports through maps to this new type.” A first check on this refactoring is by inspection of the target schema, which should look something like:

Notes

1. We will not attempt to be too precise about what is a “frame”—for us, a pre-theoretical concept—but the choice of word is intended to evoke both a “frame of reference,” meaning a chosen coordinate system or, more abstractly, a chosen point of view, and a “framework,” defined by Wikipedia as an “essential supporting structure on which other things are built.”

2. The use of Markdown files like AGENTS.md is a primitive means to mitigate this problem.

3. The evocative phrase “mathematical universe” we borrow from Ingo Blechschmidt’s paper on exploring “custom-tailored mathematical universes” using topos theory [Blechschmidt, 2022]. For technically minded readers, we remark that our usage is intended to encompass categorical-logical structures generally, not just toposes.

4. This frame is something like a countably infinite but finitely supported list of sheets. Each sheet contains a countably infinite but finitely supported grid of cells, and each cell contains a literal value or is computed by a formula referencing other cells.

5. This may seem a strange thing to say about relational databases, but note the level shift: relations in a schema are central to the standard formalism, but we are talking about relations between schemas.

6. Categorical databases and functorial migrations have been studied for the past fifteen years by applied category theorists [Spivak, 2012, Schultz et al., 2017, Lambert and Patterson, 2025, Carlson and Patterson, 2026], with a prehistory going back much further. Technology realizing this theory consistent with its philosophy (cf. [Spivak and Kent, 2012]) has been slower to develop. In past work [Patterson et al., 2022], we implemented categorical databases (ACSets.jl) and functorial data migrations (DataMigrations.jl) as in-memory data structures and embedded DSLs in the Julia programming language. While it makes creating and changing schemas lighter weight than in SQL, this software suffers from usability problems of its own, even for its intended audience of programmers. Our present effort aims to demonstrate the potential of fluid formal modeling with relational data to non-specialists.

7. The words “ticket,” “market,” and “coupon” are quoted because in the DB1B dataset they are used as airline industry jargon that may not align with their everyday use. The literate interface for defining schemas in CatColab encourages documenting the meaning of these terms in plain English.

References

Ingo Blechschmidt. Exploring mathematical objects from custom-tailored mathematical universes. In Gianluigi Oliveri, Claudio Ternullo, and Stefano Boscolo, editors, Objects, Structures, and Logics: FilMat Studies in the Philosophy of Mathematics, pages 63–95. Springer, 2022. doi:10.1007/978-3-030-84706-7_4. arXiv:2204.00948.

Kevin Carlson and Evan Patterson. Presheaves on lax double functors; or, Instances of models of double theories. Applied Categorical Structures, 34(30), 2026. doi:10.1007/s10485-026-09866-y. arXiv:2510.08861.

Michael Lambert and Evan Patterson. Representing knowledge and querying data using double-functorial semantics. Electronic Proceedings in Theoretical Computer Science, 429:174–189, 2025. doi:10.4204/EPTCS.429.9. arXiv:2403.19884.

Evan Patterson, Owen Lynch, and James Fairbanks. Categorical data structures for technical computing. Compositionality, 4(5), 2022. doi:10.32408/compositionality-4-5. arXiv:2106.04703.

Patrick Schultz, David I. Spivak, Christina Vasilakopoulou, and Ryan Wisnesky. Algebraic databases. Theory and Applications of Categories, 32(16):547–619, 2017. arXiv:1602.03501.

David I. Spivak and Robert E. Kent. Ologs: a categorical framework for knowledge representation. PLoS ONE, 7(1):e24274, 2012. doi:10.1371/journal.pone.0024274. arXiv:1102.1889.

David I. Spivak. Functorial data migration. Information and Computation, 217:31–51, 2012. doi:10.1016/j.ic.2012.05.001. arXiv:1009.1166.

Imagine a pandemic-scale surge in vaccine demand which coincides with labour shortages at a factory and constrained cold-chain capacity. Planners must decide which sites produce which medicines, how scarce inventory and freight are allocated, and which shipments are rerouted—without leaving one region short or displacing another critical product. A locally sensible choice can create failures several tiers downstream. Even in routine operations, the recent HASH/ARIA Safeguarded AI report on biopharmaceutical supply chains cites an estimated €4 billion in annual vaccine cold-chain waste in Europe and more than $35 billion in annual losses from temperature excursions across the global pharmaceutical industry.

That combination of interrelated decisions and high-consequence outcomes makes many supply chain applications ideal use cases for Safeguarded AI (SgAI). The report explains that safe AI decision-making requires three things: a world model capable of predicting an action’s consequences, an explicit specification of acceptable outcomes, and a verifier that can establish whether the resulting system satisfies that specification.

Why supply chains need Safeguarded AI

Supply chains are complex but structurally modelable.

Facilities, suppliers, transport lanes, inventories, production processes, inspections, and orders form a network of concurrent events and constrained resources. Uncertainty enters through demand, lead times, equipment failures, quality events, and disruptions. The system is difficult to reason about informally, yet its important entities and interactions can still be represented declaratively.

Many safety requirements are concrete.

Consider a temperature-sensitive vaccine shipment that is delayed while its container temperature trends towards its validated limit. The world model might track the batch’s location, temperature history, remaining shelf life, predicted weather, route-time distributions, destination demand, and available replacement stock.

The optimisation variables are the actions available to the controller: continue the journey, pause it in cold storage, select another route or transport mode, or reallocate replacement inventory. The objective might be to minimise expected waste, delay, cost, and stock-out risk. The safety specification is more categorical: never deliver a batch that has failed or still requires quality assessment; never choose an intervention that increases excursion risk; never divert stock from a higher-priority destination to a lower-priority one; and never violate approved handling or transport constraints.

This separation between what should be optimised and what must never happen (certified up to probability $\varepsilon$) is central to SgAI.

Rare, long-tail edge cases matter enormously.

Those specifications become most valuable when failures compound. A distribution plan that is safe under ordinary demand may become unsafe when a supplier failure, port closure, equipment outage, and demand spike occur together—as they might during the next pandemic-scale emergency. Historical testing can show that a policy usually performs well, but it cannot contain every consequential combination of events. SgAI instead asks whether a controller remains within its safety specification across the behaviours represented by the world model—including unlikely ones.

Modeling supply chains with Petri Nets

Petri nets are a natural candidate for building such models. Places can represent states or resources, transitions represent events or decisions, and tokens represent batches, orders, vehicles, or capacity. Coloured, timed, and stochastic extensions add product data, process durations, and uncertainty. The result is both executable and analysable: candidate policies can be simulated, while reachability, invariants, and related verification techniques identify forbidden states, deadlocks, or resource violations.

Stochastically and Dynamically Coloured Petri Nets (SDCPNs) go further by allowing token attributes to evolve as continuous stochastic processes. Semantically speaking, SDCPNs are equivalent to General Stochastic Hybrid Systems, which are expressive enough to enable the modeling of almost all cyber-physical systems (Everdij & Blom, 2010). For example, in a pharmaceutical supply chain context, SDCPNs enable us to model the moving of a cold-chain batch discretely between supplier, vehicle, warehouse, and quarantine states – while its temperature exposure, remaining shelf life, or degradation risk evolves continuously – providing a compositional model of both operational logic and physical uncertainty.

But supply chains are more than a convenient demonstration domain. They offer consequential decisions, explicit safety boundaries, rich uncertainty, and measurable outcomes—all within systems that can be formally modelled. This is a sweet spot for SgAI to demonstrate its value: enabling AI to search for better decisions while mathematical assurance determines which decisions are safe enough to act on.

As part of the SgAI programme, the open-source Petrinaut library for working with SDCPNs has been developed, and now powers this real-world supply chain modeling and optimisation capability in the HASH platform.

This post was written by Dei Vilkinsons from HASH, who lead TA1.3 of the Safeguarded AI programme. HASH’s work on the programme seeks to enable the accurate and complete modeling and specification of cyber-physical environments, and as part of TA2 they are leading efforts to apply the programme’s technology in a variety of real-world production contexts.