#Conventions & notation

The reference is written in a small, fixed notation, and reading it once here saves decoding it on every later page. This is the key: how kinds, error codes, invariants and code samples are written, how the reference marks maturity, and the frozen vocabulary the whole site shares. It owns the notation; the things the notation names — the kind system, the error policy, the determinism contract — are specified on the pages linked from each section.

New here? Start with Guide §1 — What is Flux? →

#How kinds are written

A kind is a stream’s dimension — its meaning, not only its shape. Kinds appear in code style throughout, exactly as they are written in a program or a diagnostic:

Two lower-case Greek metavariables stand in for “any kind” when a rule is generic: κ (kappa) for an element kind, and where a second is needed the plan’s own letter is used. A parameterised kind carries its parameters in parentheses (osc(lo,hi)) or braces (record{…}); a bare name (price, signal) is a kind with no parameters. The word is always kind, never “type” — “type” is reserved for the host language a Flux program is embedded in. The dimensional system these names belong to is specified in Spec — Kinds.

#Error codes are verbatim

Diagnostics are quoted exactly as the compiler emits them, in backticks, because the string is load-bearing — it is what you grep for, what the editor surfaces, and what a negative example asserts:

A code beginning Err is a compile error and rejects the program; one beginning Warn is a diagnostic that does not. The full policy — which rule raises which code, and the message text that accompanies it — is owned by Spec — Inference & the error policy. Codes are never paraphrased: a page writes [ErrDim], not “a dimension error”.

#Invariants and amendment rules

Two numbered series are referenced by number across the reference, and neither is redefined where it is cited:

• Invariants I1–I7 are the clock and determinism contract — the properties the engine holds by construction. I7, that the interpreter and the compiled WASM agree bit for bit, is the one cited most often. The contract is owned by FVM — Compiler & runtime and its proofs by FVM — Verification.
• Amendment rules A1–A15 refine the kind system past its base definition. A14 gives quantities their meas[u] unit tag — the amendment a program author meets first — and A15 reserves the metric[id] identity seam beside it. Both are owned by Spec — Kinds; the units surface that leans on A14 is FDK — units.

When a page names I7 or A14, it links the owner rather than restating the rule, so the statement lives in exactly one place and cannot drift.

#Code samples

Every fenced ```flux block is a complete, runnable program, kind-correct under the sealed grammar. A trailing // comment carries the teaching — most often the inferred kind and what it implies for presentation:

plot close   // price → main pane, price scale

plot rsi(close, input(14))   // osc(0,100) → own pane, 0–100 scale, 30/70 guides, params UI

Both lines are read back in prose after the fence; a sample is never left to speak for itself.

Negative examples show what the compiler rejects. Each is marked // ✗ with the exact error code — close + rsi(close, input(14)) // ✗ [ErrDim] — and, because Flux has no expression-statements, a rejected form is often a bare expression fragment: it demonstrates the rule, it is not a statement you could run. A page that mixes fragments into its fences says so up front in a short note on the samples, so an unmarked line is always a legal statement.

Samples are machine-checked. Every ```flux block on the site is run through the shipped parser, the shipped inference engine and the engine’s own arity table before the page ships — the same checker that guards the canonical corpus, run over this tree too — so a sample that reads as correct also is correct against the compiler that will run it. What lives outside the ANALYSIS plane the checker implements is parsed and arity-checked but not kind-checked: an app block and a collection constructor (Map, Set, Deque, Tree, Vec). A few samples that reach for a surface the ANALYSIS checker has no opinion on yet — a window verb, a variant payload, a representation, the viz.* pillar — are shown as designed code, not run.

Host-side code is fenced ```ts (TypeScript); grammar and diagrams-as-text use a plain ``` fence. The grammar itself is normative and owned by Spec — Grammar; the lexical rules behind the tokens are in Spec — Lexical structure.

#Maturity

The reference describes Flux v1 as specified, in the present tense: a page states the designed behavior of the language as the behavior it has. Maturity — what runs today versus what is sealed design still being built — is tracked in exactly one place, the status table in Implementation status, and no page repeats it.

Where the design itself holds something back — a rollout that follows v1, a seam kept open and inert, an alternative weighed and set aside — the page that reaches it explains the decision in prose, at the point it arises, rather than flagging it with a badge. Pages do not sprinkle “not yet” through the text: either a behavior is part of the design and stated plainly, or a decision was made and the page gives its reason.

#Frozen vocabulary

A handful of terms are used precisely and always the same way. The most load-bearing:

Names are fixed: Flux is the language, FDK the kit, fluxpack the package artifact, and TEA is The Elm Architecture (spelled out once per page that uses it). The planes and the firewall are specified in The four planes & the firewall; the lattice, sorts and coercion edges in Spec — Kinds. Every term with a formal definition also has a plain one in the Glossary.

#How the reference states its claims

Precision is the house style, and it extends to the guarantees. Designed behavior is written in the present tense as the behavior it is; a decision the design made against something is stated with its reason, not hedged. The guarantees are phrased exactly, and the exact phrasing is the honest one:

• Determinism is same numbers, same scene — not same pixels. A program computes bit-identical values on ARM and x86 (I7) and produces the same deterministic scene; it does not promise identical pixels across GPUs, which no engine can. The full statement is owned by Guarantees.
• The renderer is uniformly WebGPU. Scene graphics and text both render on the WebGPU path, which sidesteps the cost of DOM layout; text is an SDF glyph atlas, so type stays crisp at any zoom and DPR. Accessibility is a separate host-membrane concern (describe:/a11y: annotations), not a by-product of leaving glyphs in the DOM. The display model is owned by FDK — display.
• Work is compile-counted, not held at a frame rate. Per-step work is budgeted and counted at compile time ([ErrSceneBudget]); over-budget pressure degrades deterministically rather than being pinned to a number. The reference does not claim a guaranteed frame rate.
• Totality is a trade, stated as one. Flux is total, not Turing-complete — unbounded over time, bounded per step. It is framed as a deliberate choice with its honest examples, catalogued in Non-goals (v1).

Naming a limit as plainly as a strength is itself a convention here: a claim the docs will not hedge is one you can rely on.

#See also

• Overview — a dataflow language — the identity these conventions annotate.
• The map — every page, and the path through them.
• Implementation status — what is built versus specified.
• Spec — Kinds — the kind system, sorts, the lattice and the amendment rules.
• Spec — Inference & the error policy — which rule raises which error code.
• Glossary — every term, precisely defined.