# arc42 section 8: Cross-cutting Concepts

Checks for section 8 (Cross-cutting Concepts) of an arc42 document.

Concepts that apply to many building blocks

- The document accepts that the read side may show stale data and says where this is tolerable. → [Command Query Responsibility Segregation](https://arc.fuet.ch/concepts/data-architecture/command-query-responsibility-segregation.md)
- The conceptual data model contains no database-specific concepts such as indexes, data types or storage details. → [Conceptual Data Model](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model.md)
- The conceptual model was validated with business stakeholders, and found gaps were recorded. → [Conceptual Data Model Preparation for Logical and Physical Models](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model-preparation-for-logical-and-physical-models.md)
- The conceptual model contains no data types, tables, columns or indexes. → [Conceptual Data Model Preparation for Logical and Physical Models](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model-preparation-for-logical-and-physical-models.md)
- Relationships state cardinality and whether they are mandatory or optional. → [Conceptual data model building method](https://arc.fuet.ch/concepts/data-architecture/conceptual-data-model-building-method.md)
- The conceptual model lists entity classes and their relationships without naming any storage technology. → [Conceptual, Logical and Physical Data Model](https://arc.fuet.ch/concepts/data-architecture/conceptual-vs-logical-vs-physical-data-model.md)
- A CRUD matrix shows which processes create, read, update or delete each business data entity. → [Data Architecture](https://arc.fuet.ch/concepts/data-architecture/data-architecture.md)
- The logical data diagram gives each entity a primary key and attributes without database-specific detail. → [Data Architecture Diagram Type](https://arc.fuet.ch/concepts/data-architecture/data-architecture-diagram-types.md)
- Where applications use different formats, a common data model independent of any one application is defined. → [Data reusability and standardized access](https://arc.fuet.ch/concepts/data-architecture/data-reusability-and-standardized-access.md)
- A Data Entity/Business Function matrix shows which data supports which functions and which function owns which data. → [Define Target Data Architecture Method Phase](https://arc.fuet.ch/concepts/data-architecture/define-target-data-architecture-method-phase.md)
- The logical model names no database engine. → [Logical Data Model](https://arc.fuet.ch/concepts/data-architecture/logical-data-model.md)
- Normalization level is stated, with 3NF as the default stopping point unless a measured query says otherwise. → [Logical Data Model](https://arc.fuet.ch/concepts/data-architecture/logical-data-model.md)
- The physical model names the target DBMS and follows its naming rules. → [Logical vs. physical data model](https://arc.fuet.ch/concepts/data-architecture/logical-vs-physical-data-model.md)
- The physical model names the target DBMS it is designed for. → [Physical Data Model](https://arc.fuet.ch/concepts/data-architecture/physical-data-model.md)
- Security is described as a cross-cutting concern: who can do what to which resources, and how this is controlled, monitored and audited. → [Additional Architecture Viewpoints (Security, Information, Operational, Development, Process, Evolution)](https://arc.fuet.ch/concepts/documentation/additional-architecture-views-and-perspectives.md)
- Section 8 contains only concepts that are relevant to the system, and they are grouped. → [Crosscutting Concept](https://arc.fuet.ch/concepts/documentation/arc42-crosscutting-concepts.md)
- The building block view is present and any data structures appear as building blocks. → [Data architecture documentation in arc42](https://arc.fuet.ch/concepts/documentation/data-architecture-documentation-in-arc42.md)
- Changes to the documentation are proposed and reviewed through pull requests. → [Documentation as Code](https://arc.fuet.ch/concepts/documentation/documentation-as-code.md)
- The document is short and focused on important or risky topics. → [Guidelines for Documentation](https://arc.fuet.ch/concepts/documentation/guidelines-for-documentation.md)
- If GET requests are used, the diagram source is deflate-compressed and base64-encoded in the URL. → [Kroki](https://arc.fuet.ch/concepts/documentation/kroki.md)
- Every relationship arrow has a label stating its intent. → [Modeling Method](https://arc.fuet.ch/concepts/documentation/modeling-method.md)
- Architecture documentation is stored as plain text under version control next to the code. → [Self-Documentation](https://arc.fuet.ch/concepts/documentation/self-documentation.md)
- Recurring substructures across refinements are factored into a crosscutting concept instead of repeated. → [Undetected Duplication Antipattern](https://arc.fuet.ch/concepts/documentation/undetected-duplication-antipattern.md)
- References from outside an aggregate point only to its root. → [Aggregate](https://arc.fuet.ch/concepts/domain-driven-design/aggregate.md)
- Real-world events, such as loading or customs clearance, are recorded as domain events that feed delivery status. → [Cargo Shipping Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/cargo-shipping-domain-model-example.md)
- Where the reverse direction is needed, the document names a repository query instead of a second navigation link. → [Constraining Associations](https://arc.fuet.ch/concepts/domain-driven-design/entity-relationship-clarification.md)
- Each aggregate names exactly one root entity and states the consistency rules it protects. → [DDD Building Blocks (Tactical Patterns)](https://arc.fuet.ch/concepts/domain-driven-design/ddd-modeling-elements.md)
- Third-party or external elements are clearly marked in the building block view and shown only where needed. → [Deriving System Components from the Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/deriving-system-components-from-the-domain-model.md)
- Integration events sent to other bounded contexts are asynchronous. → [Domain Event](https://arc.fuet.ch/concepts/domain-driven-design/domain-event.md)
- The application layer is thin and the key logic sits in the domain layer. → [Domain Layer Separation](https://arc.fuet.ch/concepts/domain-driven-design/domain-layer.md)
- The model is implemented in software and has a way to evolve over the product's life. → [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md)
- Application services contain no business logic and only coordinate domain services, repositories, and transactions. → [Domain Service](https://arc.fuet.ch/concepts/domain-driven-design/domain-service.md)
- For a large domain, the document splits the model into bounded contexts instead of one unified model. → [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md)
- Each aggregate has a root that enforces its consistency boundary. → [Domain-Driven Design of the Data Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-modeling-procedure.md)
- Entity equality is based on identity only, not on attributes. → [Entity](https://arc.fuet.ch/concepts/domain-driven-design/entity.md)
- Invariants block changes to entities in terminal states. → [Entity Life Cycle](https://arc.fuet.ch/concepts/domain-driven-design/entity-life-cycle.md)
- Value objects are immutable and are compared by their attribute values. → [Entity and Value Object](https://arc.fuet.ch/concepts/domain-driven-design/entity-vs-value-object.md)
- The team's shared language is based on the domain model used in the software. → [Iterative Domain Modeling](https://arc.fuet.ch/concepts/domain-driven-design/evolutionary-domain-modeling.md)
- Modules are grouped by concepts of the domain, not by technical aspects or developer work assignments. → [Module](https://arc.fuet.ch/concepts/domain-driven-design/module.md)
- Terms that differ in meaning between groups are identified rather than merged into one. → [Ubiquitous Language](https://arc.fuet.ch/concepts/domain-driven-design/ubiquitous-language.md)
- Value objects in the model are immutable, and changes create a new object. → [Value Object](https://arc.fuet.ch/concepts/domain-driven-design/value-object.md)
- Concepts like money, ranges or points are modeled as value objects rather than bare primitives. → [Value Object](https://arc.fuet.ch/concepts/domain-driven-design/value-object.md)
- Business or domain models are documented in arc42 section 8. → [Business Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/business-architecture.md)
- Each data entity is mapped to the application or data component that holds it. → [Data Architecture Artifact](https://arc.fuet.ch/concepts/enterprise-architecture/data-architecture-artifacts.md)
- Each important data element has a named trustee accountable for its quality. → [Data Architecture Principle](https://arc.fuet.ch/concepts/enterprise-architecture/data-architecture-principle.md)
- Each entity in the matrix is linked to business functions using CRUD codes. → [Data Entity/Business Function Matrix](https://arc.fuet.ch/concepts/enterprise-architecture/data-entity-business-function-matrix.md)
- Where several roles create the same entity, the document names one owner or describes a split by role ownership. → [Data Entity/Business Function Matrix](https://arc.fuet.ch/concepts/enterprise-architecture/data-entity-business-function-matrix.md)
- Every data entity in the catalog has a definition, an owner and a classification level. → [Data Entity/Data Component Catalog](https://arc.fuet.ch/concepts/enterprise-architecture/data-entity-data-component-catalog.md)
- Logical and physical data components are kept separate, so the target architecture does not depend on a specific technology. → [Enterprise Architecture Meta Model](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-meta-model.md)
- The EA tool configuration maps each metamodel entity to a component type and each relationship to a typed reference. → [Enterprise Architecture Meta Model](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-meta-model.md)
- The document states which artifacts from the content framework are used, rather than assuming TOGAF prescribes a format. → [TOGAF](https://arc.fuet.ch/concepts/enterprise-architecture/togaf.md)
- Technical constraints are listed, with a note on which may be negotiable. → [Technology Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/technology-architecture.md)
- The document assigns responsibility for detecting faults and for handling detected exceptions. → [Architectural Decisions for Availability](https://arc.fuet.ch/concepts/forces-decisions/architectural-decisions-for-availability.md)
- Architecture and coding rules run as automated unit tests in the build. → [Architecturally Evident Coding Style](https://arc.fuet.ch/concepts/fundamentals/architecturally-evident-coding-style.md)
- Each tactic named in the document is tied to the single quality attribute it addresses. → [Architecture Means](https://arc.fuet.ch/concepts/fundamentals/architecture-means.md)
- Communication between internal services is asynchronous where possible, or the document explains why not. → [Connectors and Distribution](https://arc.fuet.ch/concepts/fundamentals/connectors-and-distribution.md)
- Tests exist that protect refactoring work as a safety net. → [Refactoring](https://arc.fuet.ch/concepts/fundamentals/refactoring.md)
- The document justifies the canonical model by the number of integrated applications, since it is overkill for only a few. → [Canonical Data Model](https://arc.fuet.ch/concepts/integration/canonical-data-model.md)
- Security tokens are not embedded in the claim check; the store enforces its own access control. → [Claim Check](https://arc.fuet.ch/concepts/integration/claim-check.md)
- For event-based flows, the document describes the end-to-end flow somewhere explicit, since it is not visible in program text. → [Connector Transparency (Direct vs Indirect Connection)](https://arc.fuet.ch/concepts/integration/connector-transparency.md)
- Where enrichment calls another source through Camel's Enrich EIP, the document states the producer cache setting. → [Content Enricher and Content Filter](https://arc.fuet.ch/concepts/integration/content-enricher.md)
- Where rules are checked in order, the order is documented, because the first match decides the branch. → [Content-based Router](https://arc.fuet.ch/concepts/integration/content-based-router.md)
- The design states that the replier copies the request ID into the correlation ID field of the reply. → [Correlation Identifier](https://arc.fuet.ch/concepts/integration/correlation-identifier.md)
- Receivers take the data type from the channel they read, not from the message content. → [Datatype Channel](https://arc.fuet.ch/concepts/integration/datatype-channel.md)
- The document states how many delivery attempts are allowed before a message moves to the dead-letter queue, and that the limit leaves room for retries. → [Dead Letter Channel](https://arc.fuet.ch/concepts/integration/dead-letter-channel.md)
- The document states whether routing-table changes at runtime are applied incrementally or replaced as a whole, and how inconsistency is handled. → [Dynamic Router](https://arc.fuet.ch/concepts/integration/dynamic-router.md)
- Where SOAP is used, headers and payload are kept separate: headers in the envelope header, content in the body. → [Envelope Wrapper](https://arc.fuet.ch/concepts/integration/envelope-wrapper.md)
- Consumers that compete on one channel are idempotent, and failing messages go to a dead-letter queue. → [Event-Driven Consumer](https://arc.fuet.ch/concepts/integration/event-driven-consumer.md)
- The document names who is responsible for transforming files between formats. → [File Transfer](https://arc.fuet.ch/concepts/integration/file-transfer.md)
- Messages with unknown or unprocessable formats have a defined destination, such as an invalid message channel. → [Format Indicator](https://arc.fuet.ch/concepts/integration/format-identifier.md)
- The document states that receivers must tolerate receiving the same message more than once. → [Idempotent Receiver](https://arc.fuet.ch/concepts/integration/idempotent-receiver.md)
- The document states whether each interaction is synchronous or asynchronous. → [Integration](https://arc.fuet.ch/concepts/integration/integration.md)
- Pattern names used in the document are neutral about technology and product. → [Integration Pattern vs. Middleware Technology](https://arc.fuet.ch/concepts/integration/integration-patterns-vs-middleware-technology.md)
- If file transfer is used, the document describes how data is transformed between application formats. → [Integration Style](https://arc.fuet.ch/concepts/integration/integration-pattern.md)
- Where Remote Procedure Invocation is used, the document acknowledges that callers are blocked during the call. → [Integration Styles](https://arc.fuet.ch/concepts/integration/integration-styles-overview.md)
- The document names a dedicated channel where the receiver puts messages it cannot process. → [Invalid Message Channel](https://arc.fuet.ch/concepts/integration/invalid-message-channel.md)
- Non-messaging applications are connected through a Channel Adapter. → [Message Channel](https://arc.fuet.ch/concepts/integration/message-channel.md)
- Each filter has a single output channel. → [Message Filter](https://arc.fuet.ch/concepts/integration/message-filter.md)
- Where one message must go to several recipients, a Recipient List sends a copy to each. → [Message Routing](https://arc.fuet.ch/concepts/integration/message-routing.md)
- The design states how out-of-order arrivals are buffered and reordered before processing. → [Message Sequence](https://arc.fuet.ch/concepts/integration/message-sequence.md)
- Request messages that expect a reply carry a unique request ID, and replies copy it into a correlation ID. → [Message Structure](https://arc.fuet.ch/concepts/integration/message-structure.md)
- The choice of a canonical model considers how many applications exchange messages. → [Message Translator](https://arc.fuet.ch/concepts/integration/message-translator.md)
- The document lists the supported protocol versions, such as MQTT 3.1.1 or 5. → [Messaging Protocol Support in Message Brokers](https://arc.fuet.ch/concepts/integration/messaging-systems-and-protocols.md)
- The document names the common target format that all translators produce. → [Normalizer](https://arc.fuet.ch/concepts/integration/normalizer.md)
- Each API endpoint has a stated role, for example Processing Resource or Information Holder Resource. → [Patterns for API Design](https://arc.fuet.ch/concepts/integration/patterns-for-api-design.md)
- Consumers on queue-based channels are designed to be idempotent, because delivery is at least once. → [Point-to-Point Channel](https://arc.fuet.ch/concepts/integration/point-to-point-channel.md)
- For queue services such as SQS, the document states whether short or long polling is used and the wait time. → [Polling Consumer](https://arc.fuet.ch/concepts/integration/polling-consumer.md)
- The document states how much each integration choice makes applications depend on each other. → [Principles Influencing EAI Pattern Selection](https://arc.fuet.ch/concepts/integration/principles-influencing-eai-pattern-selection.md)
- The document addresses the risk that the central manager becomes a performance bottleneck or a point of failure. → [Process Manager](https://arc.fuet.ch/concepts/integration/process-manager.md)
- Replies carry a correlation ID equal to the ID of the request they answer. → [Request-Reply](https://arc.fuet.ch/concepts/integration/request-reply.md)
- Replies are matched to requests with a correlation identifier alongside the return address. → [Return Address](https://arc.fuet.ch/concepts/integration/return-address.md)
- Where steps can be reversed, the document explains how compensation works for slip-based flows. → [Routing Slip](https://arc.fuet.ch/concepts/integration/routing-slip.md)
- The document states whether recipients are chosen through a Publish/Subscribe Channel or through a Recipient List. → [Scatter/Gather](https://arc.fuet.ch/concepts/integration/scatter-gather.md)
- The document states that the broker or messaging provider, not the consumer, performs the filtering. → [Selective Consumer](https://arc.fuet.ch/concepts/integration/selective-consumer.md)
- The risk of changing applications that use the shared database is acknowledged. → [Shared Database](https://arc.fuet.ch/concepts/integration/shared-database.md)
- Where one message must reach several receivers, the document names this one-to-many link. → [Software Connector Classification](https://arc.fuet.ch/concepts/integration/classification-of-integration-patterns.md)
- Where back pressure is needed, the document names the mechanism or standard used. → [Stream Connector](https://arc.fuet.ch/concepts/integration/stream.md)
- Resilience patterns such as Circuit Breaker, Bulkhead or Timeout are named where services communicate. → [Synchronous vs. Asynchronous Communication](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-communication.md)
- Consumers are designed to handle duplicate delivery, because the queue is at-least-once. → [Timeout-based Delivery](https://arc.fuet.ch/concepts/integration/timeout-based-delivery.md)
- If a service updates a database and sends a message, the document states how both are kept consistent, for example with an outbox. → [Transactional Client](https://arc.fuet.ch/concepts/integration/transactional-client.md)
- The document names the life cycle variant it uses and lists its phases. → [BPM Life Cycle](https://arc.fuet.ch/concepts/modeling-bpmn/bpm-life-cycle.md)
- The to-be state of each process is defined in a design step. → [BPM Life Cycle](https://arc.fuet.ch/concepts/modeling-bpmn/bpm-life-cycle.md)
- The team uses an automated tool to check soundness, for example by translating models to Petri nets. → [BPMN 2.0 Model Quality](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-2-0-model-quality.md)
- Every outgoing flow of an event-based gateway leads to an intermediate catch event. → [BPMN 2.0 Notation](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-2-0-notation-overview.md)
- The model states who chooses the inner activities at runtime: the engine via an expression, or a job worker. → [BPMN Ad Hoc Sub-Process](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-ad-hoc-sub-process.md)
- Each compensation boundary event links to exactly one handler through a directed association, not a sequence flow. → [BPMN Compensation Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-compensation-event.md)
- Data is connected to activities with data associations, not with sequence flows. → [BPMN Data Element](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-data-element.md)
- Every throwing link event has a catching link event with the same link name. → [BPMN Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-event.md)
- Joins that must wait for concurrent branches use a parallel gateway, not an exclusive join. → [BPMN Gateway](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-gateway-semantics.md)
- The model is checked for deadlocks and lack of synchronization, for example with a BPMN model checker. → [BPMN Gateway Mismatch Antipatterns](https://arc.fuet.ch/concepts/modeling-bpmn/antipatterns-for-process-flows.md)
- Process diagrams are modeled in one consistent direction, such as left to right. → [BPMN Layout Guideline](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-layout-guideline.md)
- Every XOR gateway shows the X marker. → [BPMN Layout Guideline](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-layout-guideline.md)
- If models are shown on a website, the document states which viewer is used for it. → [BPMN Modeling Tool](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-modeling-tools.md)
- The document states which BPMN version is used, and execution is only assumed for version 2.0 or later. → [BPMN Motivation](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-motivation.md)
- Models that are meant to run are precise enough to translate into software process components. → [BPMN Motivation](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-motivation.md)
- Each multi-instance activity is clearly drawn as parallel (vertical lines) or sequential (horizontal lines). → [BPMN Task Marker and Task Type](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-task-marker.md)
- The document states that process diagrams use BPMN as a notation that business users can read. → [BPMN as Modeling Language, Not Method](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-as-modeling-language-not-method.md)
- BPMN is used only for business-process concepts, not for other modeling needs. → [BPMN as Modeling Language, Not Method](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-as-modeling-language-not-method.md)
- Timeouts are modeled with interrupting timer boundary events, and reminders with non-interrupting ones. → [Boundary Event](https://arc.fuet.ch/concepts/modeling-bpmn/attached-boundary-intermediate-event.md)
- Constraints on how processes may change each business object are stated. → [Business Object Lifecycle](https://arc.fuet.ch/concepts/modeling-bpmn/business-object-lifecycle.md)
- The diagram uses color for no more than three distinct categories. → [Color Coding in BPMN Models](https://arc.fuet.ch/concepts/modeling-bpmn/color-coding-in-bpmn-models.md)
- The diagram has been checked in grayscale and stays readable. → [Color Coding in BPMN Models](https://arc.fuet.ch/concepts/modeling-bpmn/color-coding-in-bpmn-models.md)
- The document states which BPMN elements the models use, and the set stays small. → [Core BPMN Element Subset](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-element-usage-frequency.md)
- Swim lanes appear only at the top level, not inside subprocesses. → [Core BPMN Element Subset](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-element-usage-frequency.md)
- A reader process that polls a shared store has a timer start event with a date or cycle definition. → [Data Exchange between BPMN Processes](https://arc.fuet.ch/concepts/modeling-bpmn/data-exchange-between-bpmn-processes.md)
- Every exclusive gateway has a default flow or conditions that cover all cases. → [Deadlock in Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/deadlock-in-process-models.md)
- Decision logic sits in a DMN model, not inside the process flow; the process calls it through a business rule task. → [Decision Model and Notation](https://arc.fuet.ch/concepts/modeling-bpmn/decision-model-and-notation.md)
- Modeling of decisions starts from a Decision Requirements Diagram. → [Decision Model and Notation](https://arc.fuet.ch/concepts/modeling-bpmn/decision-model-and-notation.md)
- Where RPA bridges a legacy system, the document plans its later replacement by APIs or agents. → [Degrees of BPM Maturity](https://arc.fuet.ch/concepts/modeling-bpmn/degrees-of-bpm-maturity.md)
- No exclusive gateway merges the outgoing flows of a parallel gateway. → [Errors in Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/errors-in-process-models.md)
- The document names the BPMN version used for its process models, for example BPMN 2.0.2 as the current OMG version. → [History of BPMN](https://arc.fuet.ch/concepts/modeling-bpmn/history-of-bpmn.md)
- No exclusive gateway merges flows that were started concurrently by a parallel gateway. → [Lack of Synchronization](https://arc.fuet.ch/concepts/modeling-bpmn/lack-of-synchronization-in-process-models.md)
- Each link pair sits within one scope and does not cross a subprocess boundary. → [Link Event](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-link-event.md)
- Exception paths are modeled, for example with events that interrupt a subprocess. → [Process Analysis and Modeling](https://arc.fuet.ch/concepts/modeling-bpmn/purpose-of-process-analysis-and-modeling.md)
- Data objects are limited to the most important data aspects. → [Process Model Complexity](https://arc.fuet.ch/concepts/modeling-bpmn/process-model-complexity.md)
- Each message a process waits for names the attribute used to correlate it to the right waiting instance. → [Process Model versus Process Instance](https://arc.fuet.ch/concepts/modeling-bpmn/process-model-versus-process-instance.md)
- The conversion mapping is stated: functions to tasks, events to events, connectors to gateways. → [Process Notations Comparison (EPC, BPMN, UML Activity Diagram)](https://arc.fuet.ch/concepts/modeling-bpmn/process-notations-comparison.md)
- The check was done with a tool, and any reported violations were fixed or explained. → [Soundness of Process Models](https://arc.fuet.ch/concepts/modeling-bpmn/soundness-of-process-models.md)
- Exclusive (XOR) splits are used where exactly one path should be taken, such as alternative branches or loop exits. → [Structured Process Modeling with Fragments](https://arc.fuet.ch/concepts/modeling-bpmn/structured-process-modeling-with-fragments.md)
- Exclusive gateways are used as merges only where the incoming branches are alternatives, since they do not synchronize concurrent flows. → [Workflow Pattern](https://arc.fuet.ch/concepts/modeling-bpmn/workflow-pattern.md)
- No part is shown in more than one composition relationship at a time. → [Aggregation vs. Composition](https://arc.fuet.ch/concepts/modeling-uml/composition-versus-aggregation.md)
- Where diagrams are informal, the document notes that they may deviate from the UML standard. → [Barriers to UML Adoption](https://arc.fuet.ch/concepts/modeling-uml/barriers-to-uml-adoption.md)
- Every association line states its multiplicity. → [Common Class Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/common-class-diagram-modeling-mistakes.md)
- Each region has its own initial state and final state. → [Concurrent Region](https://arc.fuet.ch/concepts/modeling-uml/concurrent-region.md)
- Object diagrams are used to give examples or test cases for the class diagram. → [Instance Specification](https://arc.fuet.ch/concepts/modeling-uml/instance-specification.md)
- If a drawing tool is used, the team has a manual way to keep reused elements consistent across diagrams. → [Modeling Tool vs. Drawing Tool](https://arc.fuet.ch/concepts/modeling-uml/modeling-tool-vs-drawing-tool.md)
- Events that must not restart a state or abort its do activity are modeled as internal transitions, not self-transitions. → [State Entry, Exit and Do Behavior](https://arc.fuet.ch/concepts/modeling-uml/state-entry-exit-and-do-behavior.md)
- Every choice pseudostate has outgoing guards that cover all cases, so at least one is true. → [State Machine Diagram](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram.md)
- Where an else transition is used, it is the fallback for a source whose other guards can all be false. → [State Machine Diagram Modeling Mistakes](https://arc.fuet.ch/concepts/modeling-uml/state-machine-diagram-modeling-mistakes.md)
- Internal transitions are documented somewhere other than as arrows, since diagrams do not draw them. → [State Machine Transition](https://arc.fuet.ch/concepts/modeling-uml/state-machine-transition.md)
- Where several transitions react to the same event, guard conditions are given so it is clear which one fires. → [State and Event](https://arc.fuet.ch/concepts/modeling-uml/state-and-event.md)
- The parameter substitutions are listed on the binding arrow, separated by commas. → [Transfer Object Pattern as Package Template](https://arc.fuet.ch/concepts/modeling-uml/transfer-object-pattern-as-package-template.md)
- Transitions without a trigger are intended as completion transitions, and each has a guard where it should not always fire. → [Transition Syntax (Trigger, Guard, Behavior)](https://arc.fuet.ch/concepts/modeling-uml/transition-syntax.md)
- Composition (black diamond) is used only where a part belongs to a single owner. → [UML Class Diagram Relationship](https://arc.fuet.ch/concepts/modeling-uml/class-diagram-relationships.md)
- Every subclass can stand in for its superclass, because each of its instances is also an instance of the superclass. → [UML Generalization and Specialization](https://arc.fuet.ch/concepts/modeling-uml/generalization-and-specialization.md)
- No interface is shown as instantiated; each is realized by at least one class or component. → [UML Interface](https://arc.fuet.ch/concepts/modeling-uml/uml-interface.md)
- The diagrams follow the team's style guidelines consistently. → [UML Modeling Best Practice](https://arc.fuet.ch/concepts/modeling-uml/uml-modeling-best-practice.md)
- Specification diagrams describe interfaces without naming a particular implementation technology. → [UML Perspectives: Conceptual, Specification, Implementation](https://arc.fuet.ch/concepts/modeling-uml/uml-views-conceptual-specification-implementation.md)
- The Rationale gives business benefits and relates to stakeholders and their goals. → [Architecture Principle Structure](https://arc.fuet.ch/concepts/principles/structure-of-an-architecture-principle.md)
- Each module hides one design decision behind a minimal interface. → [Complexity Reduction](https://arc.fuet.ch/concepts/principles/complexity-reduction.md)
- Components expose state only through well-defined functions, and their public contracts are stable. → [Component Design Principles](https://arc.fuet.ch/concepts/principles/component-design-principles.md)
- Decisions where principles conflict are recorded with their rationale, trade-offs and consequences. → [Conflicting Architecture Principles](https://arc.fuet.ch/concepts/principles/conflicting-architecture-principles.md)
- Where an intermediary (broker, bus, mediator) is used, its added latency and its role as a possible bottleneck are assessed. → [Connect or Disconnect](https://arc.fuet.ch/concepts/principles/connect-or-disconnect.md)
- Where modules depend on each other, the document shows how strong that coupling is (loose or tight). → [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md)
- At least one change scenario has a measurable limit, such as effort in person-weeks. → [Design for Change](https://arc.fuet.ch/concepts/principles/design-for-change.md)
- The same rules for what belongs together are applied consistently across the system. → [High Cohesion](https://arc.fuet.ch/concepts/principles/high-cohesion.md)
- Each module's interface reveals as little as possible about its internals. → [Information Hiding](https://arc.fuet.ch/concepts/principles/information-hiding.md)
- No component is forced to depend on methods it does not use. → [Interface Segregation Principle](https://arc.fuet.ch/concepts/principles/interface-segregation-principle.md)
- Synchronous calls are reviewed for cascading slowdowns when a provider is slow. → [Loose Coupling](https://arc.fuet.ch/concepts/principles/loose-coupling.md)
- Module interfaces reveal as little as possible about their inner workings. → [Modularity](https://arc.fuet.ch/concepts/principles/modularity.md)
- New behavior is added through new implementations of an existing interface or through plug-ins, not by editing existing code. → [Open-Closed Principle](https://arc.fuet.ch/concepts/principles/open-closed-principle.md)
- Each element has clear responsibilities and does not mix in unrelated ones. → [Relationships Between Architecture Principles](https://arc.fuet.ch/concepts/principles/relationships-between-architecture-principles.md)
- If dependencies are inverted, the document shows business logic at the center with other parts depending on it. → [Separation of Concerns](https://arc.fuet.ch/concepts/principles/separation-of-concerns.md)
- Elements that change most quickly are kept in data, not hard-wired into code. → [Shearing Layers](https://arc.fuet.ch/concepts/principles/shearing-layers.md)
- No module groups its parts arbitrarily, such as a catch-all utility module. → [Types of Cohesion](https://arc.fuet.ch/concepts/principles/types-of-cohesion.md)
- Each principle has a memorable name and a brief, direct statement. → [Working with Principles](https://arc.fuet.ch/concepts/principles/working-with-principles.md)
- The document states that actions must be traceable uniquely to the acting entity. → [Accountability](https://arc.fuet.ch/concepts/quality-attributes/accountability.md)
- Quality properties such as security are handled by applying a perspective to each view, not by adding a separate viewpoint for each property. → [Architectural Perspective](https://arc.fuet.ch/concepts/quality-attributes/architectural-perspective.md)
- Security is treated as risk management, not as a yes-or-no state. → [Architectural Perspective](https://arc.fuet.ch/concepts/quality-attributes/architectural-perspective.md)
- The document states which subjects and resources must have a provable identity. → [Authenticity](https://arc.fuet.ch/concepts/quality-attributes/authenticity.md)
- Consumers read provider data tolerantly, taking only the elements they need. → [Compatibility](https://arc.fuet.ch/concepts/quality-attributes/compatibility.md)
- Trust boundaries are defined, and sensitive flows are segmented so only roles and assets that need them can reach them. → [Confidentiality](https://arc.fuet.ch/concepts/quality-attributes/confidentiality.md)
- The document separates faults (causes) from failures (visible deviations from the specification). → [Fault](https://arc.fuet.ch/concepts/quality-attributes/fault.md)
- The document states fault tolerance as its own quality requirement, separate from availability and recoverability. → [Fault Tolerance](https://arc.fuet.ch/concepts/quality-attributes/fault-tolerance.md)
- Hazard warning is distinguished from operational constraint, risk identification, fail safe and safe integration. → [Hazard Warning](https://arc.fuet.ch/concepts/quality-attributes/hazard-warning.md)
- Integrity is treated separately from confidentiality, which covers who may access data. → [Integrity](https://arc.fuet.ch/concepts/quality-attributes/integrity.md)
- Where two systems use different data formats, the document names the translator that converts between them. → [Interoperability](https://arc.fuet.ch/concepts/quality-attributes/interoperability.md)
- The document states which actions must be provable and how, for example with digital signatures. → [Nonrepudiation](https://arc.fuet.ch/concepts/quality-attributes/nonrepudiation.md)
- The document names a trusted third party, such as a certificate authority or time stamping authority, where proof must hold up against disputes. → [Nonrepudiation](https://arc.fuet.ch/concepts/quality-attributes/nonrepudiation.md)
- Contractual commitments (SLAs) are distinguished from internal targets (SLOs). → [Recoverability](https://arc.fuet.ch/concepts/quality-attributes/recoverability.md)
- Threat modeling identifies and prioritizes the relevant attack vectors. → [Resistance](https://arc.fuet.ch/concepts/quality-attributes/resistance.md)
- External dependencies have a documented way to manage their risks. → [Reusability](https://arc.fuet.ch/concepts/quality-attributes/reusability.md)
- The document describes the safe state the system enters or returns to after a failure. → [Safety](https://arc.fuet.ch/concepts/quality-attributes/safety.md)
- Autoscaling has a maximum instance count and throttling, and dependencies are checked against it. → [Scalability](https://arc.fuet.ch/concepts/quality-attributes/scalability.md)
- Integrity measures cover authentication, authorization and tamper detection such as digital signatures. → [Security](https://arc.fuet.ch/concepts/quality-attributes/security.md)
- The user interface is separated from the application so interface changes have limited impact. → [Usability](https://arc.fuet.ch/concepts/quality-attributes/usability.md)
- The document assesses whether routing all messages through one broker creates a bottleneck. → [Broker Pattern](https://arc.fuet.ch/concepts/styles-patterns/broker-pattern.md)
- Where control flow runs against the dependency direction, an output port interface in the inner circle resolves it. → [Clean Architecture](https://arc.fuet.ch/concepts/styles-patterns/clean-architecture.md)
- Any upward communication from a lower layer is handled through callbacks, observers or events, and is documented. → [Layered Architecture](https://arc.fuet.ch/concepts/styles-patterns/layered-architecture.md)
- The document states whether layering is strict, relaxed or mixed. → [Layers Pattern](https://arc.fuet.ch/concepts/styles-patterns/layers-pattern.md)
- The document explains how data stays consistent across services without ACID transactions. → [Microservices Architecture](https://arc.fuet.ch/concepts/styles-patterns/microservices-architecture.md)
- The model does not depend on its views, and views observe the model so several screens can show the same objects. → [Model-View-Controller Pattern](https://arc.fuet.ch/concepts/styles-patterns/model-view-controller-pattern.md)
- Subscribers are designed to tolerate messages arriving in any order. → [Publish-Subscribe Pattern](https://arc.fuet.ch/concepts/styles-patterns/publish-subscribe-pattern.md)
- The document states how consumers discover services, for example through a registry. → [Service-Oriented Architecture](https://arc.fuet.ch/concepts/styles-patterns/service-oriented-architecture.md)
- Long-running bulk operations offer a Cancel option that is easy to find and quick to use. → [Aggregate Tactic](https://arc.fuet.ch/concepts/tactics/aggregate-tactic.md)
- Each tactic is linked to the model parameters it adjusts, such as coupling, cohesion and cost for modifiability. → [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md)
- Calls between services use timeouts, so clients do not block forever. → [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactic.md)
- Where redundancy is used, the document states whether it is active-active, active-passive or a cold spare, and why. → [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics.md)
- Each redundancy choice states its cost and complexity impact. → [Availability Tactic Categories](https://arc.fuet.ch/concepts/tactics/availability-responses.md)
- The document states the failure threshold and time period that trip each circuit breaker. → [Circuit Breaker](https://arc.fuet.ch/concepts/tactics/circuit-breaker.md)
- Stored private data is encrypted at rest as an extra layer on top of access control. → [Encrypt Data](https://arc.fuet.ch/concepts/tactics/encrypt-data.md)
- Energy-saving tactics are listed together with their impact on other quality attributes, such as response time. → [Energy Efficiency Tactic](https://arc.fuet.ch/concepts/tactics/energy-efficiency-tactics.md)
- The document states how the system and its building blocks handle errors and exceptions. → [Exception Handling Tactic](https://arc.fuet.ch/concepts/tactics/exception-handling.md)
- Exception handling is tied to a detection mechanism such as heartbeat or ping/echo. → [Exception Handling Tactic](https://arc.fuet.ch/concepts/tactics/exception-handling.md)
- Where a monitor is used, it is a separate component that observes the health of other parts. → [Fault Detection Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-detection.md)
- Where state updates between components must be atomic, consistent, isolated, and durable, the document says transactions are used. → [Fault Prevention Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-prevention.md)
- Where retry is used, the document states that the faults it targets are transient. → [Fault Recovery Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-recovery.md)
- Each degradable feature has a documented fallback path, health signal and re-enable logic. → [Graceful Degradation](https://arc.fuet.ch/concepts/tactics/graceful-degradation.md)
- The heartbeat interval is longer than the network round-trip time, and the failure timeout is a multiple of the interval. → [Heartbeat](https://arc.fuet.ch/concepts/tactics/heartbeat.md)
- Fault-detection tactics such as heartbeat are named for the monitored processes. → [Integrability, Deployability, Testability and Reliability Tactics](https://arc.fuet.ch/concepts/tactics/integrability-deployability-and-testability-tactics.md)
- The document says how failed backends are detected and avoided. → [Load Balancer](https://arc.fuet.ch/concepts/tactics/load-balancer.md)
- Modules that mix non-cohesive responsibilities are identified and split, or the document explains why not. → [Modifiability Tactic](https://arc.fuet.ch/concepts/tactics/modifiability-tactics.md)
- The document states who provides service discovery, versioning and access control, and whether the registry is custom-built or a product. → [Modifiability Tactics in SOA](https://arc.fuet.ch/concepts/tactics/modifiability-tactics-in-soa.md)
- Where events differ in importance, the document describes how they are prioritized. → [Performance Tactic](https://arc.fuet.ch/concepts/tactics/performance-tactics.md)
- The document states how long a pinging component waits for an echo before declaring failure. → [Ping/Echo](https://arc.fuet.ch/concepts/tactics/ping-echo.md)
- The document states that the tactic is chosen to lower coupling between modules for modifiability. → [Reduce Coupling](https://arc.fuet.ch/concepts/tactics/reduce-coupling.md)
- The document explains how a new primary is chosen and how requests are redirected, including DNS TTL effects if DNS is used. → [Redundant Spare](https://arc.fuet.ch/concepts/tactics/redundant-spare.md)
- The retry policy sets a maximum number of attempts and states what happens after the last one. → [Retry](https://arc.fuet.ch/concepts/tactics/retry.md)
- Each hazardous operation is guarded by an explicit interlock that checks preconditions and defaults to a safe state. → [Safety Tactic](https://arc.fuet.ch/concepts/tactics/safety-tactics.md)
- Where a pattern is used, the document says which tactic it realizes. → [Security Tactic](https://arc.fuet.ch/concepts/tactics/security-tactics.md)
- The presentation is separated from the rest of the application so later interface changes stay limited in impact. → [Usability Tactic](https://arc.fuet.ch/concepts/tactics/usability-tactics.md)
- The design says whether the voter is a single point of failure or is triplicated. → [Voting](https://arc.fuet.ch/concepts/tactics/voting.md)