◆ Flux

Where to go next

You started this Guide with a single line that drew a chart, and you have arrived at complete applications — state, clocks, scenes that move, capabilities, replay you can trust. The whole language has passed under your hands. What is left is not more concepts but a map: the reference that pins down every rule you have been running on intuition, and the few doors worth walking through next depending on what you want to build. This chapter hands you off to that map, and points at the section that answers whichever question you are carrying out of the Guide.

The test of the Guide is small and concrete. Here is a program made of pieces from five different chapters, and you can now read every line of it without a footnote:

FLUX
fast = ema(close, input(12))
slow = ema(close, input(26))
plot fast
plot slow
alert fast cross_up slow or fast cross_down slow "trend change"

Two exponential moving averages over close, their windows exposed as parameters the host turns into a UI; both plotted onto the price pane because their kind says they belong there; and a signal that fires the moment they cross. Bindings and streams are Chapter 4; input and the first session are Chapter 3; ema comes from the FDK’s compute library; the pane and scale are inferred from kinds, which is Chapter 5; the cross_up signal and its alert are Chapter 7. Nothing here is new. That is the point — the rest of your learning is depth, not breadth.

Pick a door by what you’re doing next

The reference is organised so you rarely need all of it at once. Four reading paths cover almost every next step.

Writing programs. Reach for the Cookbook when you want a working recipe to adapt, and the FDK overview when you need the exact API — the namespace, the signature, the capability it costs. The FDK is the standard library: compute for dataframes, statistics and domain math; collections for bounded ordered containers; color, text, i18n, units; net for I/O; display for scenes that are not price series; server for the headless plane. Keep the Kinds page at your elbow — almost every question that begins “why won’t this compile?” is answered there.

Evaluating the guarantees. If your question is whether to trust a Flux program you did not write — the case this Guide has been quietly building toward — start with Guarantees: what is promised, and how each promise is enforced and machine-checked rather than asserted. From there, Compiler & runtime shows how the interpreter and the WASM backend are held byte-for-byte identical, and Verification & reproducible builds shows the harness that proves it. The short version, said plainly: a Flux program terminates, never rewrites its past, computes the same numbers and draws the same scene on every machine — the same reduction, not the same pixels off a given GPU — and can touch nothing it was not explicitly granted. Those are the properties that make an untrusted author safe to run, and an AI-written program is one honest instance of an untrusted author.

Extending the host. If you are embedding Flux in an application of your own — adding a representation, a drawing tool, a pane type, a new capability — Host integration is the seam you work against, and the Grammar page specifies the constructs the host binds to.

Building an interface. If what you are building is not an indicator but an island — a dashboard, a scene, a small application the engine paints beside your prose — the display planes are the reference: display for scenes and the typed style vocabulary, and the plane specs Canvas, Transitions and App. These planes are sealed design with implementation staged; the chart island is the part that runs end-to-end today, and this site’s live examples are the dogfood.

The rest of the reference, briefly

Behind those three paths sits the full reference, and it is worth knowing its shape so you can navigate by intuition rather than search. It divides into four doors.

The complete, linked catalogue lives on The map — one table of every page and what it covers. Bookmark that page rather than this one; it is the index you will come back to.

Two more places to keep open

The FAQ answers the questions the model raises the first time you push on it — including the deliberate non-goals, stated without apology. And the Glossary defines every term precisely; when a word on any page is doing more work than you expect, it is usually defined there.

A note on what “done” means for the language itself. This documentation describes Flux v1 as sealed by its design. The ANALYSIS-plane core, the WASM backend and the package format are implemented; the CANVAS, TRANSITION and APP planes and the remaining FDK pillars are sealed design with implementation staged behind them. Where a specific feature’s rollout follows v1, the page that owns it says so in prose, at the point it arises — you never have to guess. The Implementation status page carries the current ledger in one place.

That is the whole map. You have the language; the reference is where you go to be exact about it.

See also

The formal rules →