Standards
A standard is pure prose — no control flow. Stamp a different standard on the root ticket and the identical pipeline ships code, documents, research, analyses, or UI.
Five domains
Each standard supplies its domain's vocabulary, artifact evidence, workspace rules, and design principles — all under one frozen contract, so everything the library builds inside a domain stays cohesive.
Three projections
The same prose is read three ways through two callables:
- Making — what
orch-dofollows when producing work. - Planning — what
orch-dofollows when freezing a root instead, telling the planner what a well-formed one looks like in that domain. - Review — what
orch-judgefollows when challenging the result.
The artifact kind on the call names the ## Lens entry each projection reads. Same prose, three projections.
Narrowing
A standard may narrow exactly one other, which is how a house style or a single framework tightens a domain without forking it. three-js narrows javascript narrows code. The chain resolves broad to narrow, every level pinned.
standard-defect — the standard is the defect, not the artifact.
Workspace adapters
Execution selects a workspace mechanism from a closed registry — git, document-tree, or evidence-store. An explicit ticket binding wins; otherwise a supplied target, a legacy standard hint, then the current directory determine it. Ambiguity refuses. The adapter fixes workspace behavior and typed artifact identity.
Authoring
A standard's outline, slice, making, review, and vocabulary are authoring questions, not required headings. The authoring procedure is docs/standard-authoring.md, and standards/standard-craft/ carries the craft standard for standards themselves.