16 of 18 real-world TOML files validated unchanged.

We took public configuration files from six established TOML ecosystems, downloaded them directly from GitHub, and validated them against proposed schemas. The results were reproduced with the canonical Rust CLI at the pinned revision below. No source file was rewritten to fit the schema.

Inspect every result Review the method
18 public files 6 ecosystems 5 of 6 schemas passed every file 4 diagnostic paths across 2 files

A useful schema has to survive contact with existing files.

A specification can look complete while only validating its own examples. This field test deliberately moved outside the repository: package manifests, deployment settings, site configuration, worker bindings, and CI runner files from unrelated public projects.

The result is evidence that TOML Schema can describe mature, varied formats without translating them into another language. It also shows the value of strict validation: the two failures identified exact compatibility differences instead of silently accepting unknown keys.

Results by ecosystem

Each source link is pinned to the revision used where available. “Valid” means the downloaded TOML document passed the proposed schema with no modifications.

The two Hugo failures made the case for validation.

They were not parser crashes or vague incompatibilities. The validator returned exact paths for keys outside the current Hugo configuration vocabulary.

$.Params: unexpected key $.pagination.paginate: unexpected key $.languagecode: unexpected key $.defaultcontentlanguage: unexpected key

The proposed schema follows Hugo’s current documented names: params, pagination.pagerSize, languageCode, and defaultContentLanguage. A compatibility schema could choose to admit historical aliases; the current schema instead reports them visibly.

Method

  1. Search public GitHub repositories.Prefer project configuration over vendor documentation and template-only examples.
  2. Pin and download the source.Use repository content directly; do not normalize casing, remove unknown keys, or otherwise prepare it for the schema.
  3. Validate with the canonical CLI.At revision a7ced5595bda, pair each file with the corresponding pinned .tosd schema.
  4. Record every outcome.Count strict validation failures as failures and retain the diagnostic paths.
Reproduce a validation 
git clone https://github.com/brunoborges/toml-schema.git toml-schema-report
cd toml-schema-report
git checkout a7ced5595bdae08af9390f54c4997e91719b8e12
cargo run --quiet --manifest-path reference-implementations/rust/Cargo.toml -- \
  validate examples/cargo.tosd path/to/Cargo.toml

What this report does—and does not—show

Eighteen files are a field test, not a statistical benchmark or a claim of universal format coverage. The sample spans simple and complex documents but cannot exercise every key or cross-field policy. GitLab Runner files also require care because production copies commonly contain tokens; the selected public files used placeholders or empty values.

What the test does show is concrete: one small, TOML-native vocabulary described six independently evolved configuration families, accepted every selected file in five of them, and produced actionable paths for the remaining differences. That bounded result is the right starting point for trying the language against another real configuration format.

Make TOML configuration discoverable, validatable, and toolable.

Read the language proposal, try a reference implementation, or bring a real configuration format to the examples.

Read the specification Explore the schemas