Relation to the RFC
This documentation is complementary to the Courier interpreter RFC, not a replacement for it.
The Courier interpreter RFC defines the normative, enforceable specification for interpreter invocation, lifecycle, input and output structure, and interaction with the Courier Runner. It describes what the system must do and the rules that implementations are required to follow.
This guide focuses on a different, but equally important, concern: how interpreters should be designed to provide a high-quality user experience, stable contracts, and predictable behavior over time. It emphasizes intent-driven design, contract quality, failure semantics, and the architectural principles that make interpreters safe and composable.
In practical terms:
- The Courier interpreter RFC answers what’s required and how the system behaves.
- This guide answers why those requirements exist and how to design interpreters that work well within them.
Where the two documents overlap, the RFC is authoritative. Nothing in this guide supersedes or relaxes requirements defined in the RFC. Instead, this guide provides context, rationale, and best practices that help implementers apply the RFC correctly and consistently.
Readers are encouraged to use both documents together:
- Use the RFC to understand execution semantics, constraints, and guarantees.
- Use this guide to design interpreter contracts, outputs, and behaviors that users can trust and build upon.
By separating normative specification from design guidance, Courier maintains both rigor and usability, enabling the ecosystem to evolve without sacrificing stability or clarity.