Getting help

Before asking

Three commands answer most questions faster than a person can:

runtime model validate myapp   # every problem in a bundle, at once
runtime config                 # what configuration actually took effect
curl "localhost:9090/readyz?verbose"   # which dependency is unhappy

Troubleshooting covers what the common refusals mean — and most of what looks like a fault is a refusal with a reason.

Reporting a problem

What makes a report actionable, roughly in order of usefulness:

1. The diagnostic code, if there is one. M203 is unambiguous; “it says the parameter is wrong” is not.
2. The smallest bundle that reproduces it. Usually a handful of lines, and producing it often finds the answer.
3. runtime config, with the database URL redacted.
4. What you expected instead, which is where most of the value is: a refusal that is correct but surprising is a documentation bug, and worth reporting as loudly as a crash.

Unclear error messages are bugs

Worth saying separately because people do not tend to report these.

The premise of this product is that models are written by people and language models working from the schema and the diagnostics. A message that does not say what to do next is a defect in the thing the product is built on — not a small cosmetic issue. If you had to guess, that is worth a report.

Contributing to these docs

Every page has an “edit this page” link in the top right. The single most effective thing for documentation quality is making the fix take less effort than the complaint.

The site is mdBook; mdbook serve --open gives live reload. src/SUMMARY.md is the navigation, and a page not listed there is not built.