Understanding interpreters

Courier interpreters are intentionally designed to be constrained, composable, and contract-driven. Depending on a reader’s background, different mental models may make this design easier to understand.

This section presents several complementary mental models that can be used to reason about Courier jobs and interpreters. These models are explanatory only. They describe ways of thinking about the system, not its implementation. No single model is complete on its own, and none should be treated as a literal description of how Courier is built.

CI/CD pipelines and reusable actions

For many technical users, Courier jobs can be understood in a way that’s similar to modern CI/CD pipelines.

In this model:

A Courier job is analogous to a pipeline.
Each job step corresponds to a pipeline step.
An interpreter functions like a reusable action or task.
The job context plays a role similar to step outputs or shared pipeline variables.

This analogy works well because it highlights modularity, reuse, and the importance of well-defined inputs and outputs. Interpreters can be selected, combined, and reused across different jobs without rewriting logic.

The analogy intentionally breaks down in important ways. CI/CD systems often allow arbitrary scripting within steps, whereas Courier interpreters are intentionally constrained. In Courier, behavior is driven by contracts, not by free-form code. This constraint is what enables safety, predictability, and long-term stability.

Terraform providers

Another useful technical analogy is Terraform providers.

In this model:

An interpreter is similar to a provider.
The interpreter’s command schema is analogous to a resource schema.
The execution engine corresponds to the underlying API or system being managed.

This analogy emphasizes the importance of contract stability. Just as Terraform providers absorb API changes while maintaining stable resource schemas, Courier interpreters absorb engine complexity and evolution while preserving a stable user-facing contract.

The Terraform model also reinforces conservative evolution. Breaking changes to interpreter contracts are costly, just as breaking changes to provider schemas are disruptive to infrastructure workflows.

Standard Operating Procedures (SOPs)

For operational and non-technical audiences, Courier interpreters can be understood as standardized operating procedures.

In this model:

A Courier job represents a documented operational process.
An interpreter represents an approved procedure step.
The interpreter contract is the SOP itself.
The execution engine represents the tools or systems used internally to carry out the procedure.

Users don’t modify SOPs each time they’re executed. They follow approved procedures to ensure consistency, safety, and reliable auditing. In the same way, interpreters constrain how work is performed to reduce risk and variability.

Changes are constrained by design. This isn’t a limitation; it’s what makes the process reliable and repeatable.

Assembly line stations

More broadly, Courier jobs can be understood as assembly lines.

In this model:

A Courier job is an assembly line.
Each interpreter is a station on that line.
Each station accepts predictable inputs and produces predictable outputs.

Assembly lines favor reliability over flexibility. Each station performs a specific function, and the overall system works because each part behaves consistently. Courier interpreters are designed with the same philosophy.

This model highlights why interpreters focus on doing one thing well and why consistency is valued more highly than unlimited flexibility.

Choosing the correct mental model

No single mental model fully captures Courier’s architecture. Each model emphasizes different aspects of the system and resonates with different audiences.

CI/CD pipelines resonate with engineers and automation-focused users.
Terraform providers resonate with infrastructure and platform engineers.
SOPs resonate with operations and governance-oriented users.
Assembly lines resonate with business and executive stakeholders.

These models are lenses, not implementations. They exist to help users reason about Courier interpreters and jobs without needing to understand internal details. Regardless of which model is most intuitive, the underlying principles remain the same: interpreters express intent, enforce constraints, and provide stable, predictable behavior.