# arc42 section 6: Runtime View

Checks for section 6 (Runtime View) of an arc42 document.

Behavior of building blocks in important scenarios

- The description covers the logical, development, process and physical (deployment) views. → [4+1 View Model](https://arc.fuet.ch/concepts/documentation/4-1-view-model.md)
- No single all-in-one model tries to show every aspect of the system. → [Architectural View](https://arc.fuet.ch/concepts/documentation/purpose-of-views.md)
- Each view covers one aspect of the architecture and is not an overloaded all-in-one model. → [Architecture View Model](https://arc.fuet.ch/concepts/documentation/architecture-view-model.md)
- Each viewpoint names the stakeholders whose concerns it reflects. → [Architecture Viewpoint](https://arc.fuet.ch/concepts/documentation/architecture-viewpoint.md)
- Each component is described as related functionality behind a well-defined interface. → [C4 Model](https://arc.fuet.ch/concepts/documentation/c4-model.md)
- The documentation names an editor that can reopen the embedded diagrams, such as VS Code with the Draw.io Integration extension. → [Diagram Metadata in PNG (drawio.png)](https://arc.fuet.ch/concepts/documentation/diagram-metadata-in-png-drawio-png.md)
- Generated diagrams are regenerated automatically before the documentation build. → [Diagrams as Code](https://arc.fuet.ch/concepts/documentation/diagrams-as-code.md)
- The runtime view covers a representative selection of architecturally relevant scenarios. → [Essential Architecture Views (Context, Component, Runtime, Distribution)](https://arc.fuet.ch/concepts/documentation/contemporary-essential-views.md)
- Each view states which stakeholders and concerns it addresses. → [Model vs. View](https://arc.fuet.ch/concepts/documentation/model-vs-view.md)
- Every relationship line has a label that matches its direction and intent. → [Rules of Thumb for Modeling](https://arc.fuet.ch/concepts/documentation/rules-of-thumb-for-modeling.md)
- Scenarios are selected for architectural relevance, not to cover every flow. → [Runtime View](https://arc.fuet.ch/concepts/documentation/runtime-view.md)
- Each activity in a runtime scenario maps to an existing building block. → [Runtime View](https://arc.fuet.ch/concepts/documentation/runtime-view.md)
- The runtime view covers key use cases, external interfaces, start-up or administration, and error cases as scenarios. → [Runtime View](https://arc.fuet.ch/concepts/documentation/runtime-view.md)
- Each runtime scenario was chosen for its architectural relevance, and the set is a representative selection. → [Runtime View Antipattern: Code-Level Activity Diagram](https://arc.fuet.ch/concepts/documentation/runtime-view-antipattern-code-level-activity-diagram.md)
- Scenarios refer to building blocks, not to code-level elements such as package or script names. → [Runtime View Antipattern: Code-Level Activity Diagram](https://arc.fuet.ch/concepts/documentation/runtime-view-antipattern-code-level-activity-diagram.md)
- Each scenario assigns activities to building blocks, so responsibilities are visible. → [Runtime View Antipattern: Code-Level Activity Diagram](https://arc.fuet.ch/concepts/documentation/runtime-view-antipattern-code-level-activity-diagram.md)
- Any non-standard notation is accompanied by a legend. → [Self-Invented Notation Drawback](https://arc.fuet.ch/concepts/documentation/self-invented-notation-drawback.md)
- The documentation contains a building block view showing the static decomposition of the system. → [View Creation Method](https://arc.fuet.ch/concepts/documentation/view-creation-method.md)
- Domain events used inside one domain model are distinguished from integration events that cross bounded contexts. → [Domain Event](https://arc.fuet.ch/concepts/domain-driven-design/domain-event.md)
- Use cases carry a goal level, aimed at user goal or subfunction for API and service design. → [Consistency of User Story and Use Case](https://arc.fuet.ch/concepts/functional-requirements/consistency-of-user-story-and-use-case.md)
- The level of detail of each use case fits its audience, and the template is simplified where less detail is needed. → [Use Case](https://arc.fuet.ch/concepts/functional-requirements/use-case.md)
- Where a channel has several competing receivers, the document states that only one receiver consumes each message. → [Connector Cardinality](https://arc.fuet.ch/concepts/fundamentals/connector-cardinality.md)
- Each connector names its roles, so each participant in the interaction is identifiable. → [Software Connector](https://arc.fuet.ch/concepts/fundamentals/software-connector.md)
- The claim check is published only after the payload write succeeds. → [Claim Check](https://arc.fuet.ch/concepts/integration/claim-check.md)
- The document says what happens when one reply is missing or delayed, since that blocks the whole aggregate. → [Composed Message Processor](https://arc.fuet.ch/concepts/integration/composite-message-processor.md)
- Where publishers broadcast events, the document says that each subscriber gets its own copy and the publisher does not name recipients. → [Connector Transparency (Direct vs Indirect Connection)](https://arc.fuet.ch/concepts/integration/connector-transparency.md)
- Where receivers need only a few items from a large message, the document names a filtering step that removes the rest. → [Content Enricher and Content Filter](https://arc.fuet.ch/concepts/integration/content-enricher.md)
- The document distinguishes removing data inside a message (Content Filter) from dropping whole messages (Message Filter). → [Content Filter](https://arc.fuet.ch/concepts/integration/content-filter.md)
- The document states what happens to a message that matches no rule. → [Content-based Router](https://arc.fuet.ch/concepts/integration/content-based-router.md)
- The design states that each request carries a unique ID. → [Correlation Identifier](https://arc.fuet.ch/concepts/integration/correlation-identifier.md)
- Where requests expect replies on a callback queue, the document names that queue as the return address sent with the request. → [Correlation Identifier](https://arc.fuet.ch/concepts/integration/correlation-identifier.md)
- Senders have a documented rule for choosing the channel that matches the data type. → [Datatype Channel](https://arc.fuet.ch/concepts/integration/datatype-channel.md)
- Someone is named to watch and clear the dead-letter queue, since it is not cleaned automatically. → [Dead Letter Channel](https://arc.fuet.ch/concepts/integration/dead-letter-channel.md)
- The document says how the router handles a message that matches several recipients, for example first match or all matches. → [Dynamic Router](https://arc.fuet.ch/concepts/integration/dynamic-router.md)
- A dead letter queue or equivalent exists for messages that cannot be delivered. → [Enterprise Integration Patterns](https://arc.fuet.ch/concepts/integration/messaging-pattern-language.md)
- Events that must stay in order share a partition key, and the document states where order is not guaranteed. → [Event Sourcing with Distributed Event Log](https://arc.fuet.ch/concepts/integration/event-sourcing-with-distributed-event-log.md)
- Where a push consumer is used with RabbitMQ, a prefetch limit is set and is not 0 (unlimited). → [Event-Driven Consumer](https://arc.fuet.ch/concepts/integration/event-driven-consumer.md)
- The document says how duplicates are detected, for example by storing the IDs of processed messages. → [Idempotent Receiver](https://arc.fuet.ch/concepts/integration/idempotent-receiver.md)
- The document separates receiver-judged invalid content from delivery failures handled by the messaging system (Dead Letter Channel). → [Invalid Message Channel](https://arc.fuet.ch/concepts/integration/invalid-message-channel.md)
- Each channel carries one data type, so receivers can tell the message type from the channel. → [Message Channel](https://arc.fuet.ch/concepts/integration/message-channel.md)
- The design states what happens to messages that do not match: dropped, sent to a discard channel, or raised as an error. → [Message Filter](https://arc.fuet.ch/concepts/integration/message-filter.md)
- Every Aggregator that waits for replies defines a time-out strategy, so one missing message cannot block processing. → [Message Routing](https://arc.fuet.ch/concepts/integration/message-routing.md)
- Each message in a sequence carries a position identifier that orders it. → [Message Sequence](https://arc.fuet.ch/concepts/integration/message-sequence.md)
- Request messages carry a Return Address in the header rather than in the application data. → [Message Structure](https://arc.fuet.ch/concepts/integration/message-structure.md)
- If a common message format is used, it is independent of any specific application. → [Message Translator](https://arc.fuet.ch/concepts/integration/message-translator.md)
- Consumers that can see duplicate messages say how they ignore them, for example with a stable deduplication key. → [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md)
- The document explains how the router detects the format of each message, including messages with no explicit type. → [Normalizer](https://arc.fuet.ch/concepts/integration/normalizer.md)
- Where several consumers share a channel, the document notes that processing order is not guaranteed and says how order is handled if needed. → [Point-to-Point Channel](https://arc.fuet.ch/concepts/integration/point-to-point-channel.md)
- Where consumers block while waiting, the document accounts for the thread each blocked consumer uses. → [Polling Consumer](https://arc.fuet.ch/concepts/integration/polling-consumer.md)
- The document names the central unit that keeps the state of the sequence and decides the next step. → [Process Manager](https://arc.fuet.ch/concepts/integration/process-manager.md)
- The document states whether any consumer relies on the order of messages across subscribers. → [Publish/Subscribe Channel](https://arc.fuet.ch/concepts/integration/publish-subscribe-channel.md)
- Where Scatter-Gather is used, the document states whether a Recipient List distributes the requests and so controls the recipients. → [Recipient List](https://arc.fuet.ch/concepts/integration/recipient-list.md)
- Each application's data is reachable only through its exposed procedures. → [Remote Procedure Call](https://arc.fuet.ch/concepts/integration/remote-procedure-call.md)
- The reply channel is point-to-point, so replies reach only the requestor. → [Request-Reply](https://arc.fuet.ch/concepts/integration/request-reply.md)
- Requests carry a return address in the message header, so the replier does not need to know it in advance. → [Request-Reply](https://arc.fuet.ch/concepts/integration/request-reply.md)
- Request messages carry the reply destination in a header, not in the business data. → [Return Address](https://arc.fuet.ch/concepts/integration/return-address.md)
- Requesters discard replies whose correlation ID they do not recognize. → [Return Address](https://arc.fuet.ch/concepts/integration/return-address.md)
- The document states whether the slip is computed once up front or must be computed on the fly, and picks the matching pattern (Routing Slip or Dynamic Router). → [Routing Slip](https://arc.fuet.ch/concepts/integration/routing-slip.md)
- The document says whether a missing or delayed reply can block the combined result. → [Scatter/Gather](https://arc.fuet.ch/concepts/integration/scatter-gather.md)
- The document states which message headers or properties consumers select on, because selectors cannot use the message body. → [Selective Consumer](https://arc.fuet.ch/concepts/integration/selective-consumer.md)
- The document says how differences in sender and receiver speed are handled, for example by a buffer. → [Stream Connector](https://arc.fuet.ch/concepts/integration/stream.md)
- Where a sender must keep working while the receiver is down, a queue or similar asynchronous connector is used. → [Synchronous vs Asynchronous Connector](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-connector.md)
- Long chains of synchronous calls between services are identified, with a stated way to handle their combined downtime. → [Synchronous vs. Asynchronous Communication](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-communication.md)
- The visibility timeout or lock duration is set deliberately and is longer than normal processing time. → [Timeout-based Delivery](https://arc.fuet.ch/concepts/integration/timeout-based-delivery.md)
- The document states which ARIS version it follows (four views or five). → [ARIS Process Views](https://arc.fuet.ch/concepts/modeling-bpmn/aris-process-views.md)
- Process chain diagrams are filed under the control view. → [ARIS Process Views](https://arc.fuet.ch/concepts/modeling-bpmn/aris-process-views.md)
- Process models in the documentation have been checked for deadlock and lack of synchronization (soundness). → [BPMN 2.0 Model Quality](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-2-0-model-quality.md)
- The team names the modeling guidelines it follows for model quality, such as 7PMG. → [BPMN 2.0 Model Quality](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-2-0-model-quality.md)
- Each process model uses sequence flow to show the order of steps. → [BPMN 2.0 Notation](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-2-0-notation-overview.md)
- Boundary events are modeled as intermediate catch events, and each is marked as interrupting or not on purpose. → [BPMN 2.0 Notation](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-2-0-notation-overview.md)
- Reusable process logic is modeled as a call activity, not as a collapsed subprocess. → [BPMN Activity](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-activity.md)
- Each embedded subprocess has exactly one none start event. → [BPMN Activity](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-activity.md)
- Each event subprocess is marked clearly as interrupting or non-interrupting. → [BPMN Activity](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-activity.md)
- Ad hoc sub-processes in the model contain no start or end events. → [BPMN Ad Hoc Sub-Process](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-ad-hoc-sub-process.md)
- Where no completion condition is defined, the team knows the sub-process ends once all activated elements are done. → [BPMN Ad Hoc Sub-Process](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-ad-hoc-sub-process.md)
- Rules that must be enforced are modeled with real process elements, not only in text annotations, because engines ignore annotations. → [BPMN Artifacts (Group and Text Annotation)](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-artifacts-group-and-text-annotation.md)
- Operational-level process models use a separate pool per participant instead of lanes. → [BPMN Collaboration Diagram](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-collaboration-diagram.md)
- Interaction between participants is shown with message flows between pools. → [BPMN Collaboration Diagram](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-collaboration-diagram.md)
- Pools are ordered so message flows cross other pools as little as possible. → [BPMN Collaboration Diagram](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-collaboration-diagram.md)
- Each activity that may need undoing has a compensation boundary event attached to it. → [BPMN Compensation Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-compensation-event.md)
- The model triggers compensation with a throwing compensation event inside the process scope that holds the completed activities. → [BPMN Compensation Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-compensation-event.md)
- Connectors between two elements in the same pool are sequence flows, not message flows. → [BPMN Connecting Object](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-connecting-object.md)
- Communication between participants is shown as message flow between separate pools. → [BPMN Connecting Object](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-connecting-object.md)
- The default path from a decision point is marked with a slash on its sequence flow. → [BPMN Connecting Object](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-connecting-object.md)
- Every process diagram uses sequence flow to show the order of steps. → [BPMN Core Elements](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-core-elements.md)
- Each joining gateway matches its split: a parallel join where all paths must arrive, an exclusive join only where one path is taken. → [BPMN Core Elements](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-element-categories.md)
- Data stores are used for information that must outlast a single process instance, such as a database or file system. → [BPMN Data Element](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-data-element.md)
- The document states whether the tool treats data objects and data stores as modeling-only or as executable. → [BPMN Data Element](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-data-element.md)
- Where a collaboration diagram shows a partner's internals as hidden, that partner's pool is drawn as a black box. → [BPMN Diagram Types](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-diagram-types.md)
- Boundary events in the process models are intermediate catch events. → [BPMN Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-event.md)
- Terminate end events inside a subprocess are understood to stop only that subprocess. → [BPMN Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-event.md)
- Each message has exactly one sender and one recipient. → [BPMN Focus on Connected Businesses](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-focus-on-connected-businesses.md)
- Every exclusive split that has a branch without a condition declares that branch as the default flow. → [BPMN Gateway](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-gateway-semantics.md)
- Each branch of an event-based gateway leads to an intermediate catch event of type timer, message, or signal. → [BPMN Gateway](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-gateway-semantics.md)
- Every inclusive (OR) split is closed by an inclusive join, not by a parallel join. → [BPMN Gateway Mismatch Antipatterns](https://arc.fuet.ch/concepts/modeling-bpmn/antipatterns-for-process-flows.md)
- Each process run reaches any end event at most once (proper completion). → [BPMN Gateway Mismatch Antipatterns](https://arc.fuet.ch/concepts/modeling-bpmn/antipatterns-for-process-flows.md)
- Each process level has about 10 activities or fewer, so it fits on one page. → [BPMN Modeling Guidelines](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-modeling-tips.md)
- Every process shows explicit start and end events. → [BPMN Modeling Guidelines](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-modeling-tips.md)
- XOR gateways show the X symbol, carry a question, and have outgoing flows labeled as answers. → [BPMN Modeling Guidelines](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-modeling-tips.md)
- No message flow connects two elements inside the same pool. → [BPMN Swimlane (Pool and Lane)](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-swimlane-pool-and-lane.md)
- Each loop in a model targeting Camunda 7 is modeled explicitly (for example with gateways), not with the loop marker. → [BPMN Task Marker and Task Type](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-task-marker.md)
- Each compensation handler is linked by association and triggered by a compensation event, not reached by sequence flow. → [BPMN Task Marker and Task Type](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-task-marker.md)
- Error boundary events in the model are interrupting. → [Boundary Event](https://arc.fuet.ch/concepts/modeling-bpmn/attached-boundary-intermediate-event.md)
- Escalations are handled by a catch event in the nearest parent flow scope. → [Boundary Event](https://arc.fuet.ch/concepts/modeling-bpmn/attached-boundary-intermediate-event.md)
- Important business objects have their lifecycle drawn as a state machine diagram or statechart. → [Business Object Lifecycle](https://arc.fuet.ch/concepts/modeling-bpmn/business-object-lifecycle.md)
- Process events are described as business-relevant states of information objects. → [Business Object Lifecycle](https://arc.fuet.ch/concepts/modeling-bpmn/business-object-lifecycle.md)
- Analytical process models include data such as time, cost and resources where inefficiencies are to be analyzed. → [Capturing Business Behavior via Process Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/capturing-business-behavior-via-process-modeling.md)
- Each message has a single sender and a single recipient. → [Data Exchange between BPMN Processes](https://arc.fuet.ch/concepts/modeling-bpmn/data-exchange-between-bpmn-processes.md)
- Every parallel (AND) join in the process models is preceded by a parallel split, so no branch can fail to deliver a token. → [Deadlock in Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/deadlock-in-process-models.md)
- Process models have been checked for soundness, including option to complete. → [Deadlock in Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/deadlock-in-process-models.md)
- Each process model in the document contains neither a deadlock nor a lack of synchronization. → [Errors in Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/errors-in-process-models.md)
- Each outgoing flow of an event-based gateway leads to an event or receive task, not to a decision based on data. → [Event-Based Gateway](https://arc.fuet.ch/concepts/modeling-bpmn/event-based-gateway.md)
- If the target is Camunda 8, every outgoing flow of the event-based gateway ends at a timer, message or signal intermediate catch event. → [Event-Based Gateway](https://arc.fuet.ch/concepts/modeling-bpmn/event-based-gateway.md)
- Decisions based on data use a data-based exclusive gateway, not an event-based gateway. → [Event-Based Gateway](https://arc.fuet.ch/concepts/modeling-bpmn/event-based-gateway.md)
- Catching events use an unfilled icon and throwing events use a filled icon, consistently across the diagrams. → [Intermediate Event](https://arc.fuet.ch/concepts/modeling-bpmn/intermediate-event.md)
- Boundary events are modeled only as catching events. → [Intermediate Event](https://arc.fuet.ch/concepts/modeling-bpmn/intermediate-event.md)
- Timer and conditional events are modeled as catching events only. → [Intermediate Event](https://arc.fuet.ch/concepts/modeling-bpmn/intermediate-event.md)
- Every place where parallel branches from an AND split come back together uses a parallel (AND) join, not an exclusive (XOR) join. → [Lack of Synchronization](https://arc.fuet.ch/concepts/modeling-bpmn/lack-of-synchronization-in-process-models.md)
- Tasks after a merge of parallel branches run only once per process instance. → [Lack of Synchronization](https://arc.fuet.ch/concepts/modeling-bpmn/lack-of-synchronization-in-process-models.md)
- Readability and traceability, including the choreography between pools, hold from the top level to the bottom level. → [Levels of Process Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/levels-of-process-modeling.md)
- Every throwing link event has a catching link event with exactly the same name. → [Link Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-link-event.md)
- No link event is used to express business meaning; each one only replaces a sequence flow. → [Link Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-link-event.md)
- Each process has a start event and end events that show its trigger and outcomes. → [Process Analysis](https://arc.fuet.ch/concepts/modeling-bpmn/process-analysis.md)
- Exclusive gateways are labeled as questions and their outgoing flows as answers. → [Process Analysis](https://arc.fuet.ch/concepts/modeling-bpmn/process-analysis.md)
- Actors are shown as pools and lanes at the top-level process or collaboration, not inside subprocesses. → [Process Analysis and Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/purpose-of-process-analysis-and-modeling.md)
- The document states that event data for process analysis links to a case ID, activities and timestamps. → [Process Mining](https://arc.fuet.ch/concepts/modeling-bpmn/process-mining.md)
- If event data is exchanged between tools, the document names the format used, such as XES (IEEE 1849). → [Process Mining](https://arc.fuet.ch/concepts/modeling-bpmn/process-mining.md)
- Large process models are split into smaller subprocess models. → [Process Model Complexity](https://arc.fuet.ch/concepts/modeling-bpmn/process-model-complexity.md)
- Operational models use separate pools per participant rather than lanes. → [Process Model Complexity](https://arc.fuet.ch/concepts/modeling-bpmn/process-model-complexity.md)
- The document states that a model is deployed as a versioned process definition from which instances are started. → [Process Model versus Process Instance](https://arc.fuet.ch/concepts/modeling-bpmn/process-model-versus-process-instance.md)
- When EPC models are converted to BPMN, the result is reviewed for unnecessary intermediate events. → [Process Notations Comparison (EPC, BPMN, UML Activity Diagram)](https://arc.fuet.ch/concepts/modeling-bpmn/process-notations-comparison.md)
- The document states whether EPC roles become BPMN lanes or remain roles. → [Process Notations Comparison (EPC, BPMN, UML Activity Diagram)](https://arc.fuet.ch/concepts/modeling-bpmn/process-notations-comparison.md)
- Process models in the documentation have been checked for both deadlock and lack of synchronization. → [Soundness of Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/soundness-of-process-models.md)
- Each parallel (AND) split in a process model has a parallel (AND) join that waits for all its branches. → [Structured Process Modeling with Fragments](https://arc.fuet.ch/concepts/modeling-bpmn/structured-process-modeling-with-fragments.md)
- Exclusive joins are used only where paths are alternatives, since they do not wait for other paths. → [Structured Process Modeling with Fragments](https://arc.fuet.ch/concepts/modeling-bpmn/structured-process-modeling-with-fragments.md)
- Where a process runs branches in parallel, a parallel gateway splits the flow and a parallel gateway joins it again. → [Workflow Pattern](https://arc.fuet.ch/concepts/modeling-bpmn/workflow-pattern.md)
- Each exclusive split has conditions on its outgoing flows, because the gateway takes the first flow whose condition is fulfilled. → [Workflow Pattern](https://arc.fuet.ch/concepts/modeling-bpmn/workflow-pattern.md)
- Every synchronous call (filled arrowhead) has a dashed reply arrow with an open arrowhead. → [Common Sequence Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/common-sequence-diagram-modeling-mistakes.md)
- Asynchronous messages have no reply arrow. → [Common Sequence Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/common-sequence-diagram-modeling-mistakes.md)
- Asynchronous messages are marked by an open arrowhead, not by a dashed line. → [Common Sequence Diagram Mistake](https://arc.fuet.ch/concepts/modeling-uml/common-sequence-diagram-modeling-mistakes.md)
- Each region of a composite state has at most one initial state indicator. → [Composite State](https://arc.fuet.ch/concepts/modeling-uml/composite-state.md)
- Fork transitions leaving a fork target states in different regions of an orthogonal state. → [Composite State](https://arc.fuet.ch/concepts/modeling-uml/composite-state.md)
- Composite states with two or more regions are treated as orthogonal, with regions running concurrently. → [Composite State](https://arc.fuet.ch/concepts/modeling-uml/composite-state.md)
- Each orthogonal composite state has at least two regions. → [Concurrent Region](https://arc.fuet.ch/concepts/modeling-uml/concurrent-region.md)
- No transition connects states that lie in different regions. → [Concurrent Region](https://arc.fuet.ch/concepts/modeling-uml/concurrent-region.md)
- Runtime scenarios are chosen for architectural relevance, and each uses a notation that fits it, such as a sequence diagram. → [Matching Diagram Type to System Aspect](https://arc.fuet.ch/concepts/modeling-uml/matching-diagram-type-to-system-aspect.md)
- Runtime scenarios in the architecture document are shown with sequence diagrams, or another deliberately chosen scenario notation. → [Message Types in Sequence Diagrams](https://arc.fuet.ch/concepts/modeling-uml/message-types-in-sequence-diagrams.md)
- The sequence diagrams make clear what each participating building block is responsible for. → [Message Types in Sequence Diagrams](https://arc.fuet.ch/concepts/modeling-uml/message-types-in-sequence-diagrams.md)
- Entry and exit behaviors are attached to states, not duplicated on each transition. → [State Entry, Exit and Do Behavior](https://arc.fuet.ch/concepts/modeling-uml/state-entry-exit-and-do-behavior.md)
- A state with a do activity has an outgoing completion transition, or an event transition that interrupts it. → [State Entry, Exit and Do Behavior](https://arc.fuet.ch/concepts/modeling-uml/state-entry-exit-and-do-behavior.md)
- Each region has at most one initial vertex. → [State Machine Diagram](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram.md)
- Transition labels write the guard in square brackets and the effect after a slash. → [State Machine Diagram](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram.md)
- Completion transitions leaving the same state have mutually exclusive guards. → [State Machine Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram-modeling-mistakes.md)
- Transitions without a trigger are intentional completion transitions, and any guard on them is stated. → [State Machine Transition](https://arc.fuet.ch/concepts/modeling-uml/state-machine-transition.md)
- The document states that each event is processed completely before the next one is dispatched. → [State and Event](https://arc.fuet.ch/concepts/modeling-uml/state-and-event.md)
- Signal and call triggers match the receptions and operations of the owning class. → [State and Event](https://arc.fuet.ch/concepts/modeling-uml/state-and-event.md)
- Guards on transitions that compete for the same event do not overlap. → [Transition Syntax (Trigger, Guard, Behavior)](https://arc.fuet.ch/concepts/modeling-uml/transition-syntax.md)
- Each transition that should skip entry and exit behavior is modeled as an internal transition, not an external one. → [Transition Syntax (Trigger, Guard, Behavior)](https://arc.fuet.ch/concepts/modeling-uml/transition-syntax.md)
- Diagrams that show the static architecture are structure diagrams. → [UML 2.5 Diagram Taxonomy](https://arc.fuet.ch/concepts/modeling-uml/uml-diagram-taxonomy.md)
- Runtime scenarios are described with a behavior notation such as an activity diagram, sequence diagram or state machine. → [UML Behavioral Diagram](https://arc.fuet.ch/concepts/modeling-uml/behavior-diagram.md)
- Where a sequence diagram is used, it shows the responsibility of each participating building block. → [UML Behavioral Diagram](https://arc.fuet.ch/concepts/modeling-uml/behavior-diagram.md)
- Swimlanes in an activity diagram of a runtime scenario correspond to building blocks. → [UML Behavioral Diagram](https://arc.fuet.ch/concepts/modeling-uml/behavior-diagram.md)
- Runtime scenarios in the runtime view are described with sequence diagrams (or another listed notation) so each building block's responsibility is visible. → [UML Sequence Diagram](https://arc.fuet.ch/concepts/modeling-uml/sequence-diagram.md)
- Each participant in a sequence diagram has its own lifeline, and the diagram reads in time order. → [UML Sequence Diagram](https://arc.fuet.ch/concepts/modeling-uml/sequence-diagram.md)
- Each UML diagram is identifiable as a structure diagram or a behavior diagram. → [Unified Modeling Language (UML)](https://arc.fuet.ch/concepts/modeling-uml/uml-unified-modeling-language.md)
- Included use cases describe mandatory behavior; optional behavior is modeled with extend instead. → [Use Case Goal Hierarchy with Include Relationships](https://arc.fuet.ch/concepts/modeling-uml/use-case-goal-hierarchy-with-include-relationships.md)
- Runtime scenarios use sequence diagrams (or another notation) that show each building block's responsibility. → [Why Use UML in Architecture Documentation](https://arc.fuet.ch/concepts/modeling-uml/why-use-uml-in-architecture-documentation.md)
- The control component is named, and its rule for choosing the next knowledge source is described. → [Blackboard Pattern](https://arc.fuet.ch/concepts/styles-patterns/blackboard-architecture.md)
- The document explains how errors are handled in each filter, and whether retries are safe. → [Pipe-and-Filter](https://arc.fuet.ch/concepts/styles-patterns/pipe-and-filter-pattern.md)
- The document states how each filter handles breaking errors and whether it is idempotent. → [Pipes and Filters](https://arc.fuet.ch/concepts/styles-patterns/pipes-and-filters.md)
- The document states whether subscribers select messages by topic or by content filtering. → [Publish-Subscribe Pattern](https://arc.fuet.ch/concepts/styles-patterns/publish-subscribe-pattern.md)
- The document states how a tripped breaker recovers: a time-out, a health-check probe, or a manual reset. → [Circuit Breaker](https://arc.fuet.ch/concepts/tactics/circuit-breaker.md)
- Technical error handling concepts are written for developers, briefly and by priority. → [Exception Handling Tactic](https://arc.fuet.ch/concepts/tactics/exception-handling.md)
- The business has agreed which function is core when not all requirements can be met. → [Graceful Degradation](https://arc.fuet.ch/concepts/tactics/graceful-degradation.md)
- The document states what happens when heartbeats stop: a fault correction component is notified. → [Heartbeat](https://arc.fuet.ch/concepts/tactics/heartbeat.md)
- Delays between retries grow (incrementally or exponentially) and are spread across callers. → [Retry](https://arc.fuet.ch/concepts/tactics/retry.md)