Skip to main content

​
Context

STRATT is a 7-layer prompt engineering architecture. The CLI (stratt new, stratt validate, stratt publish) is the product surface users interact with — but it cannot exist without Layer 1, the schema package that defines what a valid prompt unit looks like.

​
Learning

Building the schema package first — before any CLI, before any CRDT merge logic, before any documentation site — forced every design question to be answered at the structural level. The 5 unit types (role, rule, task, chain, fragment) each have different required and forbidden blocks. Getting this right in Zod validators means the CLI can delegate all validation to a single validateUnit() call rather than implementing ad-hoc checks. The schema package also encodes business rules directly:
  • CON-010 draft isolation: Stable units cannot import draft units. This prevents untested prompts from entering production chains.
  • Composition forbidden on fragments: Fragments are reusable content, not orchestration. Preventing composition at the schema level eliminates a class of misuse.
  • CRDT merge ordering: The lifecycle state merge resolution (tombstoned > deprecated > tampered > stable > review > draft) is embedded in the schema package, not the CRDT package. This means any consumer of the schema can resolve merge conflicts without importing Automerge.

​
Business Takeaway

Investing in the schema layer before the user-facing CLI delays visible progress by approximately one week. But it eliminates an entire category of bugs (invalid prompt units reaching production) and makes every subsequent layer simpler to build. For a developer tools product where trust and correctness are the core value proposition, this tradeoff is unambiguous. The 87-test suite covering all 5 unit types, SPUH binary encoding, URI parsing, and the full validation pipeline now serves as a specification-as-code that both the CLI team and MERIDIAN documentation site can build against independently.