Shipped vs planned

Fanout is pre-release. It is used in earnest, and it changes without migration paths. This page is the account of what that means per capability, so a reader does not have to infer it from how confidently a page is written.

Every documentation page carries one of three markers in its frontmatter, and the vocabulary is closed — a fourth value fails the build rather than quietly introducing a fourth kind of claim:

Marker	What it means
shipped	The binary on the current tag does this, and the shape is settled.
preview	It runs today, and its shape may still change without a migration path.
planned	Designed and written down. Nothing executes it yet.

The marker reaches an agent too: llms.txt annotates every non-shipped page inline, so something reading the index knows before it fetches the page.

Every page states its status explicitly rather than relying on the default. That is deliberate: shipped is the schema’s default, so a page that says nothing asserts stability by silence — which is the opposite of what a pre-release product should do. Most pages here are preview because their user-facing contracts are still being refined. The marker describes the current stability of a capability; it does not imply an unlisted compatibility surface.

shipped is reserved for what has not moved and is not expected to: what Fanout is, the release and install mechanics, and backing up the data directory.

Where each capability stands

Capability	Status	Notes
OTLP ingest over gRPC and HTTP	shipped	Both transports, one port and one ingest token.
Parquet storage, trace indexes, and DuckDB analytics	shipped	Authoritative local Parquet; rebuildable DuckDB query state.
Browser client	preview	Ships in the binary; surfaces still moving.
Chat investigator	preview	Disabled unless FANOUT_AI_PROVIDER selects anthropic or openai; the selected provider’s key is required at startup.
Agent-built dashboards	preview	Build and refine from chat: fifteen panel types, variables, comparison, saved grids and immutable versions with restore. View links retain filters and time; dashboard access remains owner-scoped.
MCP tools	preview	Served at /mcp; the tool set is not frozen.
Alerts	preview	Rules evaluate on an interval against rollups.
Local email sign-in	shipped	Codes by email; no passwords.
Local self-signup	preview	FANOUT_SELF_SIGNUP, off by default. Provisions viewers after code verification only.
OIDC viewer auto-provisioning	preview	Verified identities admitted as viewers without a shared credential.
OIDC sign-in	shipped	Provider flow, with group and domain mapping.
Generated settings reference	shipped	cmd/fanout-docgen writes it; just check fails when it drifts from the type.
Release checksums and provenance	shipped	SHA256SUMS plus GitHub build attestations on every archive.
Publication benchmark	preview	A qualified candidate is visible on Performance; repeatable public artifacts are still required.
Signatures and SBOM	planned	Deliberately deferred until something consumes them.
Guides for every operational task	preview	Dashboard authoring and inspection are documented; operational coverage is still incomplete.
Namespace scoping on alert rules	planned	The field is stored but evaluation ignores it; scope with service.

What “no migration path” means in practice

It means what it says. A storage-format change may require starting from an empty data directory. The configuration loader rejects unknown FANOUT_ setting names, except platform-injected service-discovery names, so a typo surfaces as a refusal to start rather than as a silently ignored value.

Do not run a Fanout instance as the only copy of data you need to keep.