Most product pages hide this list. We publish it, above the fold, because a tool for engineers should survive being checked — and because finding an edge after buying wastes your fab budget, which is the exact thing Fluidraft exists to protect.
Fluidraft's solver is an incompressible, laminar, single-phase hydraulic network model: an exact steady-state solve, plus a distributed 1D transient model in which pressure events genuinely propagate along channels (an R-C transmission line, ~100 µm segments — P(x,t) is reported per branch). It answers "which branch gets how much flow, at what pressure, settling in how long" — fast, and validated against closed-form solutions. It will not simulate turbulence (which physically does not occur at chip Reynolds numbers), multiphase interfaces, or droplet break-up: droplet T-junctions get a labeled reduced-order generator prediction (Garstecki 2006 scaling — plug volume, frequency, spacing), which is withheld outside its validity range rather than extrapolated. And when a design truly needs field CFD, Fluidraft exports a ready-to-mesh OpenFOAM case — the true fluid-domain surface, snappyHexMesh setup, and the actual fluid's properties, with the one remaining manual step named in the README instead of hidden. We hand off to CFD; we don't imitate it.
The 3D view is a 2.5D engineering visualization of the true fabrication geometry — real cross-section profiles, real substrate thickness, honest enough to measure against. It exports true-scale STL and, since v1.1, real STEP solids on the OpenCascade B-Rep kernel: exact prisms for rectangular processes, true profile sweeps for dome and circular ones, round-trip verified. What it still does not do — by choice — is freeform solid sculpting, booleans and 3D fillets: editing is 2D-parametric, because planar microfluidics is 2D with depth, and a second modeling paradigm would dilute the one that makes designs simulable.
Design-rule and manufacturability checks are indicative — they encode published process knowledge, not a guarantee from your fab. Simulation results become a validated digital twin only after you calibrate against measured operating points from a fabricated device; the Calibration tab exists for exactly that workflow, and until you've done it our own documentation calls the model "calibration-ready", nothing more. Fluidraft's outputs are not evidence of regulatory compliance of any device, medical or otherwise, and we will never suggest they are.
The FABRIX manufacturing module reports a deterministic readiness grade — a classification of design-rule violations whose exact logic is printed in the product and in every payload. It is not a production-yield or success-probability figure, and it will not become one until there are validated manufacturing datasets to build such a figure on. The shipped process profiles are generic and describe themselves as indicative; manufacturer-verified PDKs are future work and will be labeled as a different thing. FABRIX is also not a foundry marketplace: no RFQs, no automatic quotes, no fabrication ordering. And base Fluidraft never depends on it — everything on this page's "does do" side works identically with the module locked, and a project carrying FABRIX settings opens unchanged anywhere.
The optimisation engine contains no flow equations of its own: every candidate is your full project solved by the same deterministic solver as the SIMULATE button, and a test re-solves candidates by hand to one part in a million. There is no neural network proposing geometries, no stochastic magic — the search is a bounded, reproducible grid, and the same study run twice produces byte-identical results. Hard constraints are never traded off. And nothing ever touches your design until you explicitly accept a candidate; acceptance is one normal, undoable edit.
Droplet behaviour depends on geometry, fluids, wetting and regime — one equation stretched over everything would be fiction. Predictions come from a model registry where each model states its source, its exact definitions and its validated domain, and refuses to answer outside it: EXTRAPOLATED and UNSUPPORTED are answers you will actually see, with the reason, instead of a confident wrong number. Interfacial pair values are never invented — your measurement wins, library values are cited and labelled indicative, unknown pairs stay unknown. Displays carry two significant figures, because a reduced-order correlation does not know a droplet to six decimals. It is not multiphase CFD, and it says so.
No cloud sync, no accounts, no multi-user collaboration. Your projects are files on your machine. This is a deliberate v1 choice, and it is also why the product makes no telemetry calls and works behind a lab firewall — the licence itself is verified fully offline.
Today the full product runs from source (Python 3.11+, a two-minute install) or Docker; the browser demo needs nothing at all. Packaged, signed installers for Windows and macOS are on the roadmap and will be announced when they ship — not before.
The demo is the real UI with a TypeScript port of the engine running client-side. Its rule-check engine is reduced, and the Python core remains the canonical implementation. The differences are enumerated in the source, in apps/web/src/demo/engine.ts.
The multi-temperature fluid property editor, validated process-specific rule packs backed by an experimental campaign, and signed installers are all planned. None of them appear elsewhere on this site as if they exist, and a price rise, if one comes, will be tied to one of them actually shipping — never to a date.