Choose a concrete trigger
Begin with one observable event: a person submits a form, an API receives a request, a timer fires or a consumer receives a message. Identify the input and the component that accepts it. Keep the question narrow enough that you can follow one operation to a meaningful outcome.
In the Meridian example, order submission is a useful starting point. The product includes an HTTP path, durable state, asynchronous delivery and fulfillment. Each is a different part of the explanation, even though they serve one user action.
Use Behavior for choices and outcomes
A Behavior view describes authored steps and transitions. Follow the successful path, then inspect validation, authorization, rejection and recovery branches. Ask where the system promises an outcome and which state makes that promise durable.
The file should distinguish an accepted operation from a completed downstream effect. A queued delivery, for example, can remain pending after the initiating request succeeds. If a branch or outcome is missing from the model, mark it as a question for source analysis instead of assuming it cannot occur.
Use Interactions for the conversation
An Interactions view lays out declared messages between participants. Read the message order, endpoints and notes to understand which component calls another or publishes an event. This complements the component relationships in Architecture.
The diagram is an authored explanation, not a live distributed trace. Message order should not be treated as a measured production timeline. Check evidence and source revision before drawing conclusions about a system’s current behavior or latency.
Investigate the asynchronous boundary
For a queue or event stream, identify the producer, destination and consumer separately. Ask what is persisted before publication, how duplicate delivery is handled and what happens if a consumer crashes after committing work but before acknowledging the message.
Useful records may describe deduplication keys, retry limits, backoff, dead-letter handling, ordering, replay and compensation. The authoring process should investigate these concerns where relevant. The presence of a queue glyph alone proves none of them.
Connect recovery to obligations
Visit Specification to inspect the requirements associated with the flow. A requirement might state that retrying an accepted command must not create a second order, or that a failed downstream operation remains visible for recovery. Read its acceptance criteria and supporting evidence.
This path connects the picture to something a developer can review and test. Use feature scope to keep the related services and records together, then consult the review guide before treating an explanation as established behavior.
Explore a fictional example, or open your own .ospec file locally.
Open 1view →