Stargraph
The open-source runtime Railyard is built on.
A stateful agent-graph framework that composes LLMs, classical ML, and tools into auditable, replayable graphs where deterministic CLIPS rules decide every transition instead of a model.
What Stargraph does.
No static edges. Transitions are derived at runtime by Fathom, a CLIPS rules engine, matching rules against typed facts in working memory. The language model never picks the next step, so control flow is inspectable and free of stochastic drift.
Every fact carries its origin, source, run, step, confidence, and timestamp. Origins are typed as llm, tool, user, rule, model, or external, so a rule can reason about where a value came from and not only its content.
sklearn, XGBoost, PyTorch, and ONNX models run as first-class nodes alongside DSPy modules. Route on a cheap model's confidence and fall back to an LLM or a human gate only when it is unsure.
Checkpoint pinning and structural graph hashing make deterministic replay free. Re-execute a run from any step with a mutated rule, node output, or fact, then diff against the original.
Stargraph owns the orchestration layer.
Each tool in the Kraken stack owns a single concern. Stargraph sits at the orchestration tier — adopt it on its own, or descend the whole column.
Stargraph is the open-source runtime that Railyard is built on. Where Railyard packages the full platform, with a Go API, a React dashboard, and hosted governors, Stargraph is the Python engine underneath: a stateful agent-graph framework you embed in your own code or run with stargraph serve. Same architecture, no managed surface. It composes LLM calls, classical ML inference, tools, and retrieval into typed graphs, then lets deterministic rules decide what runs next.
In most agent frameworks the language model is both worker and router. It does the thinking and picks the next step, which turns control flow into a sample from a distribution you cannot replay. Stargraph splits the two jobs apart. Nodes do work. Fathom, a CLIPS rules engine, decides every transition by matching rules against provenance-typed facts in working memory. The same facts fire the same rules in the same order on every run, so the decision layer is inspectable, versioned, and free of stochastic drift.
Every fact carries its origin, source, run, step, confidence, and timestamp, so a rule can reason about where a value came from rather than just its value. Checkpoint pinning and structural graph hashing make replay deterministic: re-run from any step with a mutated fact, output, or rule, then diff against the original. The whole stack is designed to run where other orchestrators cannot, behind a one-way diode or on an isolated network, with zero outbound calls once dependencies and embedding weights are staged locally.