otto schema — the data contracts, exported¶
otto schema is the smallest of the first-party commands and the purest
expression of the data-boundary design:
because every external file otto reads is validated by a pydantic model,
those same models can be emitted as JSON Schemas. otto schema export writes schemas for
hosts.json, .otto/settings.toml, and reservation files; editors pick
them up for completion and inline validation
(Editor schemas (autocomplete for hosts.json & settings.toml)).
What is unique about schema¶
Fully
lab_free. It never loads a lab, creates no output directory, and runs no gate — it reflects models, full stop. It is the reference example of a command that opts out of everything in the preamble (The command lifecycle).Single source of truth. The schema is generated from the exact model that validates ingest, so documentation, editor tooling, and runtime validation cannot disagree. When a host-spec field changes, the exported schema changes in the same commit — there is no second definition to update.
Extensions surface automatically. Because project-registered host classes bring their own spec models (The host subsystem), a repo that extends otto sees its fields in the export;
--builtins-onlyrestricts to otto’s own types.