The Model Is the App

You run a help desk. Two people answer tickets, tickets arrive faster some hours than others, and when customers wait too long they give up and leave. You have questions: should the next hire be a third agent? What happens during a surge? How many customers are you losing right now that you never see?

The traditional answers are a spreadsheet you don't quite believe or a custom app you can't afford. sim.pflow.xyz is the third answer, and it rests on one design claim:

A declarative vocabulary of composable models that provides analysis and an app framework — from the same artifact.

Three claims in one sentence. Each is checkable, so let's take them one at a time.

Claim 1: A declarative vocabulary

Your help desk is a JSON document in a small, fixed vocabulary: places (things that hold — a queue, a staff pool, a ledger of resolved tickets), transitions (things that happen — arrive, pick up, resolve, give up), and arcs (what each happening consumes and produces). That's a Petri net, and it has carried state machines, chemistry, and workflow theory for sixty years.

On top of the net, the vocabulary admits declarations — statements about the model that a machine can check, not comments that rot:

• Rates and kinetics. How fast things happen, and with which discipline. An agent doesn't answer faster because the queue is longer — a prerequisite is not an accelerant — and that rule is an annotation on the arc, enforced by the engine, not a caveat in prose.
• Outcomes. Which terminal places count as success and which as loss, so every analysis agrees on what "lost a customer" means.
• Decisions. A budget, the things it can buy (declared at rate zero — dormant until an operator chooses), and an objective: "resolved minus three times abandoned."
• Players. Who decides, what they maximize, whose turn it is. Declare these and your model is a game the engine can solve.
• Views. The screens of the app: each one a named projection of the model — this dashboard shows the queue, this controls screen turns the staffing knobs, this advisor screen prices your options — with a prompt saying what the screen is for.

Declarative means there is nothing else. No application code beside the model that could disagree with it, no formula hidden in a cell. Every statement is validated on the way in — a view naming a place the model doesn't have is an error, not a stale comment — and the model's identity is the hash of its content, so "which version" is never a question.

The LLM's role falls out of this design: its job is to get your operation into the vocabulary. A conversation, not a coding project. Everything downstream is derived deterministically — same model, same results, same app, every time.

Underneath, this is the functional paradigm expressed with models instead of code. The model is a value, not a program: firing a transition is a pure function from marking to marking; the state of a running app is a fold over its event log; every analysis is a pure function of the document; composing two models is function composition with the lineage recorded. There is no hidden mutable state anywhere in the chain — which is precisely what makes replay, receipts, and same-seed-same-bytes possible. We didn't bolt determinism on; we inherited it from the paradigm.

One more property, and it matters because of where ideas like this have died before: the metamodel is open where earlier model-driven systems were closed. A CASE tool or a low-code platform holds your model hostage — it means nothing outside the runtime that rents it back to you, and when the platform disappoints, you exit with screenshots. This model is plain JSON with public semantics: a Petri net means what sixty years of literature says it means, the vocabulary's extensions are documented claims a validator checks, and the same model has been held to one canonical trace across 39 independent implementations in ten languages. The catalog is CC0. If the service vanished tomorrow, your models would still mean exactly what they mean today. The worst case of betting on this is owning a pile of precisely-defined documents — which is the difference between SQL, which outlived every vendor that shipped it, and the closed tools that surrounded it, which are gone.

Claim 2: Composable

Most operations are built from the same handful of shapes: things arrive, things wait, staffed pools serve them, impatience leaks them, stock reorders at a threshold, messages buffer in an inbox. The vocabulary ships these as components — templates with ports you attach onto places your model already has.

Three calls compose the help desk from the opening paragraph: arrivals, then a service attached to its queue, then a hazard (the customers who give up) attached to the same queue. Each call returns a new content-addressed model with its lineage recorded — composition is an auditable derivation, not an edit.

The important part is what rides inside the templates. Each component carries its calibration discipline in its structure: the service's pickup arc is non-kinetic so service speed can't scale with queue length; the staff pool is held across the whole job so headcount is observably binding; the loss sink is fed by a bare hazard so the analysis reads it as loss without being told. These rules were each learned the hard way while building the catalog. A composed model is born following them — the discipline is in the template, not in the reviewer.

Claim 3a: Analysis

Because the model is declarative, analysis is a reading of the document — and one document admits many readings, which can be forced to agree:

• Simulate it: seeded stochastic runs, side-by-side scenario comparisons on the same dice, time-varying schedules for the morning rush.
• Diagnose it: every knob ranked by measured influence, conservation checked, the thing your operation actually waits on named.
• Prove things about it: ask for its invariants and the algebra hands back laws like budget + 3*technicians + 2*spares + … == 16 — the pricing of your decisions, discovered in the structure, checkable with grade-school arithmetic.
• Cross-check it: the same model runs discretely and continuously, and divergence is reported as a finding with a reason. For an epidemic model, the gap between the two readings at the infected place is the probability the outbreak fizzles — something the smooth curve structurally cannot see.
• Solve it: where players and an objective are declared, exhaustive search plays perfectly. The catalog's tic-tac-toe bot is provably unbeatable — and if you beat it, you've falsified the system. Nobody has.
• Calibrate it: upload an event log — just case, activity, timestamp rows — and the rates are learned from your own history, with a conformance report saying how well the structure fits your data before you believe any of it. This is the moment a catalog template becomes your help desk.

None of these readings was written for a specific model. They are functions of the vocabulary, so every model — including the one you compose five minutes from now — gets the entire suite for free.

Claim 3b: An app framework

The same document is the application. The views declarations are the screens; a click fires one of the model's transitions; the state you watch is the model's marking. Published apps run sandboxed against the model's public API — the app cannot claim anything the model doesn't say.

And because analysis and app share one artifact, the app gets the analysis as features:

• The advisor button prices your decisions by simulating the declared objective — "the third agent is worth +9, the marketing push costs you −4" — derived from your model, not from a heuristic someone hard-coded.
• The trust panel renders the invariants the algebra found, live against the running state, so the conservation law is a thing you watch hold rather than a promise.
• Every seeded run can return a signed receipt — a certificate over the model id, the scenario, and the result hash that anyone can replay and verify without trusting you, me, or the server. Same dice, same bytes.

This is the metamodel vision: the model completely defines the application, categorically. Structure, dynamics, decisions, screens, provenance — one artifact an LLM can write, a machine can validate, and a person can play.

Where this goes

The pattern generalizes past help desks. A model with players and an objective is a game. A model with a budget and rate-zero decisions is a planning tool whose advisor prices every option. A model calibrated monthly against your event logs is a digital twin that tells you when reality has drifted from your assumptions. Different products, same vocabulary, same derivations.

Everything in this post is live. The catalog is CC0 — nineteen models from coffee shops to epidemic dynamics to loan books, each a template that becomes yours in one calibration call. Connect any MCP client to https://sim.pflow.xyz/mcp, describe your operation, and play the model it hands back.

The spreadsheet gave you totals. The model gives you the app.