star-toml
Version: v26.6.29
A framework for loading, layering, validating, and admitting configuration files in Rust — the * in *.toml.
Most configuration frameworks parse a file into a struct and stop. star-toml treats configuration as operational law and provides the core substrate for config admission.
Do not build a path.
Build the bounded space of paths,
the laws that admit them,
the generators that manufacture them,
the detectors that falsify them,
the witnesses that preserve them,
and the gate that decides standing.
Crate Ecosystem
| Crate | Description |
|---|---|
star-toml |
Core admission framework — schema, layering, validation |
star-toml-derive |
Procedural macros for custom validator derivation |
star-toml-json-schema |
JSON Schema bridge — import/export, 16-check bridge validation |
star-toml-config-test |
Runtime conformance test helpers and DfCM matrix runner |
star-toml-lsp |
LSP server — live diagnostics, hover cards, release-verifier commands |
🏛️ The Core Thesis: Configuration is Operational Law
Most software systems do not fail because they lack code. They fail because their operational law is implicit, underbounded, or non-witnessed.
star-toml replaces narrative authority ("trust me, it works") with machine-visible standing:
- Raw Parse ≠ Trusted Config: Syntactically valid TOML is not an admitted configuration.
- OCEL = Lifecycle/Process History: Process-mining logs (
wasm4pm-compatOCEL export) record the process history but do not compute $q_{config}$ or grant standing. - q_config = Standing Decision: The configuration standing bit ($q_{config} = 1$) is calculated from pipeline completeness, witness integrity, and an empty failset.
- AdmittedConfig: The terminal, immutable, witness-backed envelope representing a configuration with standing.
🚀 The Config Admission Pipeline
star-toml enforces a strict, typestate-guaranteed admission pipeline:
Raw (String/File)
↳ BoundedSources (Source list checked)
↳ Merged (Traced layer merge)
↳ EnvResolved (Prefixed environment variables)
↳ Deserialized<T> (Schema alignment)
↳ Validated<T> (Pydantic-grade custom rules)
↳ Frozen<T> (Immutable representation)
↳ CanonicalSaved (Alphabetically sorted, deterministic serialization)
↳ Witnessed (BLAKE3 hash binding all provenance inputs)
↳ AdmittedConfig<T> (Terminal admitted config)
🛠️ Usage Example
use ;
use ;
📐 DfCM (Design for Combinatorial Maximalism)
star-toml is designed under the DfCM discipline. MVP asks: "What is the smallest happy path?" DfCM asks: "What is the complete bounded variant space this system must survive?"
Every configuration loader evaluates:
- Sources: Inline, required file, optional file, environment.
- Layers: Defaults $\rightarrow$ base $\rightarrow$ profile $\rightarrow$ env.
- Paths: Validated against Sandbox, RelativeOnly, or BlockForbidden policies.
- Validation: Invariant rules with error or fatal severities.
🔍 Verification & Conformance
star-toml includes a built-in verifier that checks for active counterexamples (such as directory traversals, unknown fields accepted in trusted mode, and validation errors without paths) to ensure the release has absolute conformance.
Run the verifier report:
Run DfCM examples: