Commands, queries, events, and business errors

This module gives the domain an event-storming and CQRS vocabulary: state-changing commands, reads, events, errors, and conditions.

Source: mde/metamodels/cim/cim-behavior.emf.

`Command`

Represents command in the CIM vocabulary. It specializes TraceableElement with the details needed for this modeling concern.

Direct supertypes: TraceableElement. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`intent`	`String` [1]	The state-changing business request, stated as an outcome rather than a transport operation. CIM-to-PIM uses it when shaping the function and API contract that realize the request. Semantic validation: `DuplicateSubmissionCommandHasIdempotencyKey` (duplicate submission command has idempotency key) in `mde/validation/cim/rules/behavior.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Command2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`. ETL rule `UserInitiatedCommand2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Reserve inventory for a confirmed order`.
`userInitiated`	`Boolean` [1]	Whether the command originates from a user-facing interaction. The distinction helps the transformation choose API exposure and keeps system reactions separate from user intent. Transformation role: ETL rule `Command2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`. ETL rule `UserInitiatedCommand2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`.	Either `true` or `false`. Example: `false`.
`idempotencyBusinessKey`	`String` [1]	The domain key by which repeated submissions represent one business action. It is the evidence needed to construct an idempotency policy instead of relying on a technical request ID. Semantic validation: `DuplicateSubmissionCommandHasIdempotencyKey` (duplicate submission command has idempotency key) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `Command2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `orderId`.
`duplicateSubmissionPossible`	`Boolean` [1]	Whether retries, double clicks, or redelivery can cause the same intent to arrive more than once. When true, the model must explain how duplicate effects are prevented. Semantic validation: `DuplicateSubmissionCommandHasIdempotencyKey` (duplicate submission command has idempotency key) in `mde/validation/cim/rules/behavior.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `Command2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`.	Either `true` or `false`. Example: `false`.
`auditRequired`	`Boolean` [1]	Whether execution of this state-changing intent must leave an auditable record. The requirement follows the command into security, observability, and generated documentation. Semantic validation: `ExternalOrUntrustedCommandRequiresAuditAndAuthorization` (external or untrusted command requires audit and authorization) in `mde/validation/cim/rules/behavior.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `Command2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`.	Either `true` or `false`. Example: `true`.
`authorizationRequired`	`Boolean` [1]	Whether permission must be checked before the command is accepted. It is a business decision about access, not a promise that a particular authorizer has already been chosen. Semantic validation: `ActorFacingCommandHasAuthorizationDecision` (actor facing command has authorization decision) in `mde/validation/cim/rules/behavior.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Command2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`. ETL rule `UserInitiatedCommand2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`.	Either `true` or `false`. Example: `true`.
`authorizationRule`	`String` [1]	The business rule that determines who may issue the command. It gives PIM authorization policies something more meaningful to preserve than a generic 'secured' flag. Semantic validation: `ActorFacingCommandHasAuthorizationDecision` (actor facing command has authorization decision) in `mde/validation/cim/rules/behavior.evl` the feature participates in a semantic validation condition. `ExternalOrUntrustedCommandRequiresAuditAndAuthorization` (external or untrusted command requires audit and authorization) in `mde/validation/cim/rules/behavior.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `UserInitiatedCommand2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`. ETL rule `UserInitiatedCommand2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` reads or derives this feature while refining `Command`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `actor.role = 'order-manager'`.
`commandType`	`CommandType` [1]	The origin and intent category of the command, distinguishing a human request from an external-system, policy, correction, or cancellation command.	Exactly one of: `USER_INTENT`, `BUSINESS_SYSTEM_INTENT`, `EXTERNAL_SYSTEM_INTENT`, `POLICY_TRIGGERED_INTENT`, `CORRECTION`, `CANCELLATION`. Example: `USER_INTENT`.
`interactionExpectation`	`InteractionExpectation` [1]	The response expectation attached to the command. It is the CIM signal used to decide whether PIM should favor request/response handling, asynchronous acceptance, or human review. Transformation role: ETL rule `UserInitiatedCommand2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Command`.	Exactly one of: `IMMEDIATE_RESPONSE_EXPECTED`, `RESPONSE_CAN_BE_DELAYED`, `NOTIFICATION_EXPECTED`, `BACK_OFFICE_PROCESSING`, `HUMAN_REVIEW_REQUIRED`. Example: `IMMEDIATE_RESPONSE_EXPECTED`.
`priority`	`Priority` [1]	The business urgency of the command, useful for ordering work and operational attention without changing its domain meaning.	Exactly one of: `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`. Example: `LOW`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`outcomes` → `CommandOutcome`	containment, [*]; opposite `command`	Contains the command outcome element(s) that make up this command; the contained objects belong to this model element.
`issuedBy` → `Actor`	reference, [*]; opposite `issuesCommands`	References the actor element(s) used as issued by by this command; the target may be shared elsewhere in the model.
`targetCapability` → `BusinessCapability`	reference, [?]; opposite `containsCommands`	References the business capability element(s) used as target capability by this command; the target may be shared elsewhere in the model.
`targetAggregate` → `AggregateCandidate`	reference, [?]	References the aggregate candidate element(s) used as target aggregate by this command; the target may be shared elsewhere in the model.
`input` → `InformationItem`	reference, [*]	References the information item element(s) used as input by this command; the target may be shared elsewhere in the model.
`preconditions` → `Condition`	reference, [*]	References the condition element(s) used as preconditions by this command; the target may be shared elsewhere in the model.
`expectedEvents` → `BusinessEvent`	reference, [*]; opposite `expectedByCommands`	References the business event element(s) used as expected events by this command; the target may be shared elsewhere in the model.
`rejectionEvents` → `BusinessEvent`	reference, [*]; opposite `rejectedByCommands`	References the business event element(s) used as rejection events by this command; the target may be shared elsewhere in the model.
`possibleErrors` → `BusinessError`	reference, [*]	References the business error element(s) used as possible errors by this command; the target may be shared elsewhere in the model.

`CommandOutcome`

Represents command outcome in the CIM vocabulary. It specializes TraceableElement with the details needed for this modeling concern.

Direct supertypes: TraceableElement. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`success`	`Boolean` [1]	For a command outcome, the model records whether success applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	Either `true` or `false`. Example: `true`.
`resultDescription`	`String` [1]	Stores the human explanation of result description on the command outcome. The field records human review and generated guidance as an explicit, reviewable input. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Processes confirmed orders for the owning capability.`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`command` → `Command`	reference; read-only, [1]; opposite `outcomes`	References the command element(s) used as command by this command outcome; the target may be shared elsewhere in the model.
`emittedEvents` → `BusinessEvent`	reference, [*]	References the business event element(s) used as emitted events by this command outcome; the target may be shared elsewhere in the model.
`errors` → `BusinessError`	reference, [*]	References the business error element(s) used as errors by this command outcome; the target may be shared elsewhere in the model.
`output` → `InformationItem`	reference, [*]	References the information item element(s) used as output by this command outcome; the target may be shared elsewhere in the model.

`Query`

Represents query in the CIM vocabulary. It specializes TraceableElement with the details needed for this modeling concern.

Direct supertypes: TraceableElement. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`intent`	`String` [1]	The information the requester wants to learn, not the eventual database query. It guides the output contract and keeps read behavior anchored in a business question. Transformation role: ETL rule `Query2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`. ETL rule `Query2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Find an order by its business identifier`.
`confidentiality`	`String` [1]	The confidentiality expectation of the returned information. It informs authorization and prevents a read path from being treated as harmless merely because it does not mutate state.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Query Confidentiality`.
`authorizationRequired`	`Boolean` [1]	Whether access to the answer must be controlled. Sensitive reads often require the same rigor as commands even though they do not change data. Semantic validation: `PersonalQueryMustDeclareAuthorization` (personal query must declare authorization) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `Query2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`. ETL rule `Query2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`.	Either `true` or `false`. Example: `true`.
`authorizationRule`	`String` [1]	The domain-level rule that decides who may see the query result, later refined into PIM authorization policy or route security. Semantic validation: `PersonalQueryMustDeclareAuthorization` (personal query must declare authorization) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `Query2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`. ETL rule `Query2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` reads or derives this feature while refining `Query`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `actor.tenantId = order.tenantId`.
`auditRequired`	`Boolean` [1]	Whether querying the information is itself an auditable act, which is common for regulated or security-sensitive data. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`.	Either `true` or `false`. Example: `true`.
`containsPersonalData`	`Boolean` [1]	Whether the result can expose personal data. The flag connects read behavior to privacy obligations and the authorization rule. Semantic validation: `PersonalQueryMustDeclareAuthorization` (personal query must declare authorization) in `mde/validation/cim/rules/behavior.evl` the flag must be enabled for this rule to pass. `QueryPersonalFlagMatchesOutput` (query personal flag matches output) in `mde/validation/cim/rules/behavior.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Query2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`. ETL rule `Query2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`.	Either `true` or `false`. Example: `false`.
`paginationExpectation`	`String` [1]	How the business expects large result sets to be divided for consumers. It informs API contract shape and storage access patterns without prescribing a framework. Semantic validation: `ListSearchQueryDeclaresResultHandling` (list search query declares result handling) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `Query2ApiRoute` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Query Pagination Expectation`.
`filteringExpectation`	`String` [1]	The filtering behavior users need, such as status, date range, or tenant. It helps derive indexes and query parameters rather than leaving performance to guesswork. Semantic validation: `ListSearchQueryDeclaresResultHandling` (list search query declares result handling) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Query Filtering Expectation`.
`sortingExpectation`	`String` [1]	The ordering users consider meaningful. Stable sorting is often part of pagination correctness, so this is a contract decision rather than presentation decoration. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Query Sorting Expectation`.
`queryType`	`QueryType` [1]	The kind of read, lookup, list, search, report, status, or analytics, which helps transformations choose an appropriate function, route, and access pattern. Semantic validation: `ListSearchQueryDeclaresResultHandling` (list search query declares result handling) in `mde/validation/cim/rules/behavior.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Query2Function` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`. ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`.	Exactly one of: `LOOKUP`, `LIST`, `SEARCH`, `REPORT`, `STATUS`, `ANALYTICS`. Example: `LOOKUP`.
`freshnessNeed`	`FreshnessNeed` [1]	How current the answer must be. It is the business justification for strong reads, projections, cache policy, or eventual-consistency trade-offs in PIM. Semantic validation: `QueryDeclaresFreshness` (query declares freshness) in `mde/validation/cim/rules/behavior.evl` the related value or object must be explicitly provided. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Query`.	Exactly one of: `REAL_TIME`, `NEAR_REAL_TIME`, `EVENTUALLY_CONSISTENT`, `PERIODIC`, `HISTORICAL`. Example: `REAL_TIME`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`input` → `InformationItem`	reference, [*]	References the information item element(s) used as input by this query; the target may be shared elsewhere in the model.
`output` → `InformationItem`	reference, [+]	References the information item element(s) used as output by this query; the target may be shared elsewhere in the model.
`reads` → `DomainEntity`	reference, [*]	References the domain entity element(s) used as reads by this query; the target may be shared elsewhere in the model.
`issuedBy` → `Actor`	reference, [*]; opposite `issuesQueries`	References the actor element(s) used as issued by by this query; the target may be shared elsewhere in the model.
`targetCapability` → `BusinessCapability`	reference, [?]; opposite `containsQueries`	References the business capability element(s) used as target capability by this query; the target may be shared elsewhere in the model.

`BusinessEvent`

Represents business event in the CIM vocabulary. It specializes TraceableElement with the details needed for this modeling concern.

Direct supertypes: TraceableElement. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`semanticName`	`String` [1]	The stable business name of the fact after it has happened. It becomes event vocabulary and a contract identity, not merely a message label. Semantic validation: `EventHasBusinessMeaning` (event has business meaning) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `BusinessEvent`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `OrderConfirmed`.
`occurredInPastTenseName`	`String` [1]	A past-tense rendering that makes event meaning grammatically unmistakable in process and event-storming views. Semantic validation: `EventNamePastTense` (event name past tense) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `BusinessEvent`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Order was confirmed`.
`businessMeaning`	`String` [1]	The business fact conveyed by the event and why consumers should care. It prevents an event from degenerating into a technical notification with no domain contract. Semantic validation: `EventHasBusinessMeaning` (event has business meaning) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `A confirmed order is one accepted for fulfillment by the business.`.
`businessTimestampItemName`	`String` [1]	The payload item that represents when the business event occurred. Separating business time from recording time is essential for correct ordering and reporting.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `occurredAt`.
`correlationBusinessKey`	`String` [1]	The business identifier that lets related events and commands be followed across a process, such as an order, claim, or application number.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `orderId`.
`causationBusinessKey`	`String` [1]	The business key of the action or event that caused this fact. It supports auditability and causal tracing beyond infrastructure request IDs.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `orderId`.
`orderingKeyCandidate`	`String` [1]	A candidate partition/order key for consumers that must process related facts in sequence. The transformation can carry it into channel and messaging design. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `BusinessEvent`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `orderId`.
`externallyVisible`	`Boolean` [1]	Whether the event is part of an external contract. External visibility raises versioning, compatibility, security, and documentation expectations. Semantic validation: `ProductionRelevantEventHasVersioningMetadata` (production relevant event has versioning metadata) in `mde/validation/cim/rules/behavior.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `BusinessEvent`.	Either `true` or `false`. Example: `false`.
`auditRelevant`	`Boolean` [1]	Whether publishing or consuming the event contributes to the audit trail of the domain. Semantic validation: `ProductionRelevantEventHasVersioningMetadata` (production relevant event has versioning metadata) in `mde/validation/cim/rules/behavior.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `BusinessEvent`.	Either `true` or `false`. Example: `true`.
`retentionRelevant`	`Boolean` [1]	Whether the event has lasting business or regulatory value, influencing event retention and durable archive decisions. Semantic validation: `ProductionRelevantEventHasVersioningMetadata` (production relevant event has versioning metadata) in `mde/validation/cim/rules/behavior.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `BusinessEvent`.	Either `true` or `false`. Example: `false`.
`semanticVersion`	`String` [1]	The contract version of the business event. It lets consumers reason about compatibility independently from deployment versions. Semantic validation: `ProductionRelevantEventHasVersioningMetadata` (production relevant event has versioning metadata) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. `EventSemanticVersionLooksLikeSemVer` (event semantic version looks like sem ver) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `BusinessEvent`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `1.0.0`.
`versioningRationale`	`String` [1]	Why the chosen event version is compatible or intentionally breaking. It records the decision that protects consumers during schema evolution. Semantic validation: `ProductionRelevantEventHasVersioningMetadata` (production relevant event has versioning metadata) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `The choice protects the business outcome while keeping the design independently deployable.`.
`eventTimeSemantics`	`EventTimeSemantics` [1]	Which clock the event's time refers to, business occurrence, observation, or recording, so consumers do not compare timestamps with different meanings.	Exactly one of: `BUSINESS_TIME`, `OBSERVATION_TIME`, `RECORDING_TIME`. Example: `BUSINESS_TIME`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`expectedByCommands` → `Command`	reference, [*]; opposite `expectedEvents`	References the command element(s) used as expected by commands by this business event; the target may be shared elsewhere in the model.
`rejectedByCommands` → `Command`	reference, [*]; opposite `rejectionEvents`	References the command element(s) used as rejected by commands by this business event; the target may be shared elsewhere in the model.
`causedByExternalSystems` → `ExternalSystem`	reference, [*]; opposite `producedEvents`	References the external system element(s) used as caused by external systems by this business event; the target may be shared elsewhere in the model.
`consumedByExternalSystems` → `ExternalSystem`	reference, [*]; opposite `consumedEvents`	References the external system element(s) used as consumed by external systems by this business event; the target may be shared elsewhere in the model.
`causedByPolicies` → `Policy`	reference, [*]; opposite `emitsEvents`	References the policy element(s) used as caused by policies by this business event; the target may be shared elsewhere in the model.
`consumedByPolicies` → `Policy`	reference, [*]; opposite `triggeredBy`	References the policy element(s) used as consumed by policies by this business event; the target may be shared elsewhere in the model.
`consumedByProcesses` → `BusinessProcess`	reference, [*]	References the business process element(s) used as consumed by processes by this business event; the target may be shared elsewhere in the model.
`payload` → `InformationItem`	reference, [*]	References the information item element(s) used as payload by this business event; the target may be shared elsewhere in the model.
`affects` → `DomainEntity`	reference, [*]	References the domain entity element(s) used as affects by this business event; the target may be shared elsewhere in the model.

`BusinessError`

Represents business error in the CIM vocabulary. It specializes TraceableElement with the details needed for this modeling concern.

Direct supertypes: TraceableElement. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`errorCode`	`String` [1]	The stable domain code that callers and contracts can branch on. It is more durable than a localized message and is transformed into an error schema field. Semantic validation: `BusinessErrorIsUserUnderstandable` (business error is user understandable) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `BusinessError2ErrorSchema` in `mde/transformations/cim-to-pim/behavior-contracts.etl` reads or derives this feature while refining `BusinessError`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `ORDER_NOT_FOUND`.
`businessMeaning`	`String` [1]	What the failure means in the business, distinguishing a rejected business outcome from a transport or infrastructure exception. Semantic validation: `BusinessErrorIsUserUnderstandable` (business error is user understandable) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `A confirmed order is one accepted for fulfillment by the business.`.
`userVisibleMessage`	`String` [1]	The safe explanation a user or consumer may receive. It is carried into the generated error contract and must not leak secrets or internal stack details. Semantic validation: `BusinessErrorIsUserUnderstandable` (business error is user understandable) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. Transformation role: ETL rule `BusinessError2ErrorSchema` in `mde/transformations/cim-to-pim/behavior-contracts.etl` reads or derives this feature while refining `BusinessError`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Order could not be completed.`.
`recoverable`	`Boolean` [1]	Whether the business situation can be resolved through retry, correction, or another compensating action. Semantic validation: `BusinessErrorIsUserUnderstandable` (business error is user understandable) in `mde/validation/cim/rules/behavior.evl` the feature participates in a semantic validation condition. `RetryMeaningfulImpliesRecoverable` (retry meaningful implies recoverable) in `mde/validation/cim/rules/behavior.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `BusinessError2ErrorSchema` in `mde/transformations/cim-to-pim/behavior-contracts.etl` reads or derives this feature while refining `BusinessError`.	Either `true` or `false`. Example: `false`.
`retryMeaningful`	`Boolean` [1]	Whether repeating the operation has a plausible chance of success. EVL requires this to be consistent with recoverability so retry policies are not generated blindly. Semantic validation: `RetryMeaningfulImpliesRecoverable` (retry meaningful implies recoverable) in `mde/validation/cim/rules/behavior.evl` the flag must be enabled for this rule to pass.	Either `true` or `false`. Example: `false`.
`auditRequired`	`Boolean` [1]	Whether the occurrence must be recorded for accountability, even if it is recoverable and never becomes a production incident.	Either `true` or `false`. Example: `true`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`emittedEvents` → `BusinessEvent`	reference, [*]	References the business event element(s) used as emitted events by this business error; the target may be shared elsewhere in the model.

`Condition`

Represents condition in the CIM vocabulary. It specializes TraceableElement with the details needed for this modeling concern.

Direct supertypes: TraceableElement. Inherited attributes and marker capabilities are documented in the shared kernel; this section lists every attribute declared by this class.

Declared attributes

Attribute	Type and multiplicity	What it captures and why it exists	Accepted values and example
`naturalLanguage`	`String` [1]	The stakeholder-readable statement of the condition, preserving the rule for reviewers who should not have to read an expression language. Semantic validation: `ConditionIsSpecified` (condition is specified) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Condition Natural Language`.
`expression`	`String` [1]	The machine-oriented form of the condition when automation is required. It gives transformation a concrete predicate instead of asking it to interpret prose. Semantic validation: `ConditionIsSpecified` (condition is specified) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank. `AutomatableConditionHasExpression` (automatable condition has expression) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`mustBeAutomatable`	`Boolean` [1]	Whether the process is allowed to depend on a human judgment here. When true, EVL requires an expression model so the eventual workflow can execute the decision. Semantic validation: `AutomatableConditionHasExpression` (automatable condition has expression) in `mde/validation/cim/rules/behavior.evl` the flag must be enabled for this rule to pass.	Either `true` or `false`. Example: `false`.
`expressionLanguage`	`ExpressionLanguage` [1]	The language in which the expression is written. Declaring it prevents JSONPath, FEEL, OCL, or natural language from being treated as interchangeable strings. Semantic validation: `AutomatableConditionHasExpression` (automatable condition has expression) in `mde/validation/cim/rules/behavior.evl` the value must be present and non-blank.	Exactly one of: `NATURAL_LANGUAGE`, `OCL`, `FEEL`, `JSONPATH`, `JSONATA`, `JAVASCRIPT`, `TYPESCRIPT`, `PYTHON`, `SQL`, `REGEX`, `OTHER`. Example: `NATURAL_LANGUAGE`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`expressionModel` → `Expression`	containment, [?]	Contains the expression element(s) that make up this condition; the contained objects belong to this model element.
`referencedInformation` → `InformationItem`	reference, [*]	References the information item element(s) used as referenced information by this condition; the target may be shared elsewhere in the model.
`referencedConcepts` → `DomainConcept`	reference, [*]	References the domain concept element(s) used as referenced concepts by this condition; the target may be shared elsewhere in the model.