Start with an entrypoint and an owner
Pick an action a person or another system can initiate. It might be an HTTP request, a scheduled job or an incoming event. Find the first component that receives it, then identify the service that owns the resulting durable state.
In the Meridian example, the storefront, edge gateway, checkout API and commerce database are separate objects. This separation lets you ask which component authenticates a caller, which coordinates a transaction and which holds the authoritative record. A business label such as “checkout” alone cannot answer those questions.
Read connections as contracts
Select a relationship and inspect its declared endpoints, purpose and protocol. An arrow may describe an HTTP call, an event publication, a database operation or ownership. Its direction matters: a consumer receiving a queued message is different from a caller waiting for an immediate response.
Look for missing information. If the file does not state whether a connection is synchronous, what it carries or how failure is handled, ask the authoring agent to investigate the relevant source. The viewer displays the specification; it does not fill in missing contracts.
Separate responsibility from hosting
Architecture explains a component’s role. Runtime views help explain its placement: for example, a service hosted on a virtual machine, a function at an edge provider, or a database managed elsewhere. One service can depend on resources in several environments.
Inspect the declared hosting and boundary records rather than assuming that neighboring cards share a network or provider. A cloud service, a private queue and a process on a custom VM can belong to the same product. 1view can represent mixed infrastructure when the file describes it.
Go deeper without losing the route
Select an object and use its available exploration controls to reach internals or related views. Use the anchor to bring an exact object into context. Back and Forward help retrace a path through the system; Whole product returns to the broad view.
The active diagram occupies the working plane. Other diagrams appear through explicit navigation, instead of obscuring the current work. Use the artifact list to locate an object by name when the complete diagram is too large to scan comfortably.
Turn the picture into a review
Before changing a component, identify its callers, dependencies, data authority and external boundaries. Then inspect the behavior and interaction views for failure paths. A topology diagram can show that a queue exists without explaining duplicate delivery or recovery.
Check the evidence and source revision behind important claims. A proposed deployment is a plan; source-inspected configuration is evidence about that revision. Neither automatically proves what is running in production today.
Explore a fictional example, or open your own .ospec file locally.
Open 1view →