Solve the system, not just the equation
An engineering agent is only useful if you can check it. FlowMechanics prints its own arithmetic, labels where every number came from, and stops when the data will not carry a conclusion.
The datasheet number is not the number in the pipe
Let methane down from 4,500 psig and the stream arrives at roughly −41 °F. The valve body, being heavy steel, cools far more slowly than the gas moving through it, so for the first minutes of the blowdown the metal and the gas are at completely different temperatures. The elastomer seal reaches its low temperature limit long before the assembly gets anywhere near its pressure rating.
None of that appears on the datasheet, because the datasheet describes a component and the failure belongs to a system. This is the ordinary condition of high-pressure gas work: the arithmetic that matters spans compressible flow, real-gas behavior, and transient heat transfer at once, and no single catalogue equation crosses those boundaries.
Engineers solve it today with a spreadsheet inherited from somebody who left, a vendor sizing tool that only knows that vendor’s products, and judgment. The spreadsheet is usually right and nobody can prove it.
A language model is the wrong place to put the physics
The obvious build is to hand a capable model the standards and let it answer. We did not do that, and the reason is the whole design.
A model asked to compute will produce a fluent, confident, plausibly formatted answer whether or not it has the grounding to support one. It does not fail loudly. It fails like a competent colleague who misremembered, which in engineering is the worst possible failure mode, because it survives review.
The dangerous output is not the error. It is the error that looks exactly like the correct answer.
So the physics lives in deterministic calculation engines and the model is confined to two jobs: understanding what was asked, and explaining what the engines returned. It never supplies a number. Every figure that reaches the user is classified at the point of display as computed, cited, or convention, so a reviewer can see immediately which parts of an answer are arithmetic and which are engineering custom.
Two engines that have to agree
Correctness needed a check that did not depend on us being careful. The approach was to implement the core thermodynamics twice, independently, and hold the two implementations to agreement within 1e−9. A divergence beyond that tolerance is not smoothed over or averaged. It stops the answer.
It is a deliberately expensive way to build. It is also the only mechanism we know of that catches the specific bug that matters here: a transcription or unit error that produces a number which is wrong but entirely reasonable-looking. Two engines written from the same physics but different code paths do not usually make the same mistake.
On top of that sits the property library: 137 fluids sized from a reference equation of state, 49 of them carrying fitted transport properties, and 84 knowledge sections behind the explanations, every figure in them classified the same way the computed output is.
What we built
Sizing that shows its working
IEC 60534-2-1 and ISA 75.01.01 sizing across choked and sub-critical regimes, with required Cₕ, Kₕ, effective area, Mach and erosion limits. The output is not just the result: it prints the relation, then the same relation with this problem’s numbers substituted in, then the result. An engineer can check it by hand, which is the only form of trust that counts on a stamped drawing.
Real-gas behavior across the full range
Compressibility, density, speed of sound, Joule–Thomson, phase and saturation, freeze risk. Worth being precise about one thing here, because the first draft of our own marketing copy got it wrong: gases do not universally cool on throttling. Hydrogen has a Joule–Thomson inversion temperature near 202 K, so throttling hydrogen anywhere near ambient makes it warmer. The engine knows that. The copy had to be rewritten to match the engine rather than the intuition.
Thermal and transient analysis
Heavy-wall body cooldown over time, steady-state metal against gas temperature, lumped-capacitance validity tested by Biot number rather than assumed, preheat duty, and elastomer limits. This is the part that catches the seal failure the datasheet hides.
A refusal layer, ordered correctly
Certain questions must never be answered by software, however good the physics is — whether a design meets code, whether a material is safe in a given service. Those route to the governing standard and to the person who has to sign for it. We shipped that check in the wrong order the first time: the topic gate ran first and rejected a legitimate materials-compatibility question as off-topic before the safety layer ever saw it. The safety check now runs before everything else, which is where it always belonged.
Edge deployment, nothing retained
The whole product runs at the edge on Cloudflare Workers, with the front end served as static assets from the same worker. Conversations are not stored. An origin lock keeps the inference endpoint from being used as somebody else’s free API.
What we would do again
Three things this build taught us that transfer to any technical agent.
Stem your retrieval keys, then test the miss
An early version matched the corpus key choked but not choke. A user asking about choke conditions retrieved nothing, and the model, having no grounding, answered from memory with physics that was subtly wrong and perfectly fluent. That is the lesson in one sentence: on a grounded agent, a retrieval miss does not produce an error, it produces a confident wrong answer. Keys are stemmed now, and the test suite deliberately probes near-misses.
Make refusal a feature, not an apology
Every agent project is pushed toward answering everything, because an answer feels like value and a refusal feels like failure. In engineering it is the reverse. A tool that declines cleanly when the data will not support a conclusion is a tool an engineer can put in front of a reviewer. One that always answers is one they have to double-check, which means it saved nobody anything.
Let the model talk, never let it calculate
The separation is worth defending hard, because there is constant pressure to blur it — the model is right most of the time, and routing through an engine is more work. Most of the time is not a standard anyone builds pressure equipment to.
Where it goes next
The current build is a working engine with a public front end, not a finished commercial product, and we would rather say that than imply otherwise. There are no adoption numbers on this page because there is nothing yet worth charting.
The direction from here is P&ID authoring with rule checking, regulator part number construction against real vendor catalogues, and outlet tolerances stated tightly enough that a vendor can be held to them. All of it depends on the same foundation: computed numbers a reviewer can verify by hand, and a system willing to say when it does not know. Related work in PolyAtlas took the same approach in plastics.