Skip to content

Reference

Exhaustive, per-entity documentation for everything in Helix. If a guide explains how to use a feature, the reference explains what every knob does.

Sections

Section What it covers Entity count
Components URI schemes (http://, kafka://, …) — every flag, header, and behavior knob 67 schemes
Processors EIP processors (aggregate, choice, split, …) — every parameter ~24 files, 50+ processors
Agent Agent types, flows, memory backends, tools, guardrails, skills 7 types + 5 subsystems
RAG Chunkers, embedders, stores, retrievers, postprocessors, readers, generators, graph, RAPTOR, cache 12 sub-packages, ~80 impls
Connectors The 440-connector SDK, organized by category 33 categories
CLI Every helix <subcommand> and its flags 22 subcommands
Schemas JSON Schemas for the YAML DSL — validated by helix validate 23 schemas
DSL The YAML DSL itself: workflow shape, REST DSL, OpenAPI loader, route templates 4 features
Starlang Every built-in Starlang function — signature and description, per module 373 functions

Conventions

  • Source-of-truth: every reference page has a Source line linking to the Go package or file it documents. If the code changes, the page changes — bin/audit-docs is the gate.
  • URI shape: components use scheme://<path>?<params> with path semantics documented per scheme.
  • Params lead with prefix: Producer: / Consumer: / Both: / Path token: so it's obvious which role a param applies to. This is enforced in the Describable source; the docs mirror the prefix.
  • Examples are runnable: every snippet should validate via helix validate. CI runs audit-docs and (eventually) extracts and validates these examples.