The five elements
Five recurring pieces appear across the four workflow patterns.
Event — a fact that already happened
An Event is a concrete fact in the domain, named in the past tense: Appointment Added, Pet Added, Payment Received, Weather Forecast Changed.
In .em.hcl, Events are canonical contracts owned by a bounded context:
The label is the identity. appointment_added gets the derived title Appointment Added; add title only for different wording.
Rule of thumb: if the thing can still be rejected, it is probably not an Event yet.
Command — an intent to make something happen
A Command represents a request or intent. It can succeed or fail: Add Appointment, Add Pet, Cancel Subscription.
Commands live inside workflows and point to the Event(s) they may produce:
A Command needs an incoming flow, an api_endpoint, or external_trigger. Otherwise the validator reports EM404.
Read Model — an answer to a concrete question
A Read Model answers one concrete question.
No question, no Read Model.
The language makes that discipline explicit by requiring question:
"What data is needed?" is vague. "Which appointments do not yet have a weather forecast?" defines the projection.
Screen — where an actor observes or initiates behavior
A Screen is a UI, rough wireframe, or other human-facing interaction point.
Actors are reusable catalog declarations referenced with traversals such as actor.calendar_user.
Automation / gear — a machine reaction
The gear on the visual cheat sheet means the computer reacts instead of a human.
Visual gear concept → processor block.
Automation pattern → automation workflow block.
automation is a top-level workflow kind. Its machine reaction is a processor.