SeedSpec specification
The normative SeedSpec Protocol: language definition, field-level specification, operation contracts, schemas, and the conformance corpus.
What is normative
Protocol behavior is defined by the specification, the versioned schemas, and the conformance corpus — nothing else. Guides, examples, and evaluation findings explain the design; they do not constrain an implementation.
The specification text lives in the repository so it versions with the code that implements it. This page is the index.
Language definition
Concepts, the authority model, the processing lifecycle, operations, and what a result does and does not claim. Read this before the field-level rules.
Protocol 0.2 specification
Exact field-level rules for the package manifest, configuration, capabilities, artifacts, tasks, resources, resolution, and verification state.
Operation contracts
What each protocol operation must accept, produce, and refuse.
Versioned schemas
The 29 JSON Schemas that bind the format. Served from this domain at a stable address.
Conformance corpus
The cases an independent implementation must satisfy, and what passing them establishes.
Three claims the protocol keeps apart
| Claim | Established by |
|---|---|
| An independent tool can interpret this package. | Schema validation and the conformance corpus. |
| The seed communicates the important intent well. | Authoring review and human judgment. Not a protocol result. |
| This implementation satisfied the selected intent. | Scoped completion evidence recorded against the realization. |
A valid package is not automatically a strong one, and a strong specification does not guarantee a correct implementation. Keeping these separate is what lets the protocol be strict about structure without implying correctness.
Explanatory material
Authoring tools
This site covers the protocol. The tools for writing a SeedSpec — guided review, the authoring workspace, and walkthroughs written for an author rather than an implementer — live at seedspec.ai.