Processes, policies, and decisions

These classes express end-to-end business processes, branching decisions, policies, waits, human work, and exception handling.

Source: mde/metamodels/cim/cim-process-policy.emf.

BusinessProcess

The CIM-level description of a business journey from its trigger to its completion criterion. Its contained steps and transitions describe what the organization does; its exceptions and temporal constraints make failure and timing part of the business definition before orchestration technology is selected.

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
businessTriggerDescription	String [1]	A plain-language account of what starts the business process when the trigger cannot yet be expressed as a typed event, command, actor, or model element. It keeps the process reviewable during discovery; the CIM trigger validation accepts it as an explicit alternative, while later refinement can replace it with a typed trigger. Semantic validation: ProcessHasTriggerAndCompletionCriterion (process has trigger and completion criterion) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Transformation role: ETL rule BusinessProcess2Workflow in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining BusinessProcess.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: Processes confirmed orders for the owning capability..
longRunning	Boolean [1]	Marks a process whose work can outlive a normal request/response interaction. This is a business timing decision, not a Lambda timeout setting: the CIM validation requires temporal constraints for it, and the CIM-to-PIM transformation uses it when shaping a workflow and its duration/resilience policies. Semantic validation: LongRunningProcessHasTemporalConstraint (long running process has temporal constraint) in mde/validation/cim/rules/process-policy.evl the flag must be enabled for this rule to pass. Transformation role: ETL rule BusinessProcess2Workflow in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining BusinessProcess.	Either true or false. Example: false.
humanApprovalPossible	Boolean [1]	Says that a human decision can be part of the process rather than being an implementation accident. PIM refinement uses the fact when deciding whether the workflow needs a human/approval task and its associated timeout, assignee, and escalation concerns. Transformation role: ETL rule BusinessProcess2Workflow in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining BusinessProcess.	Either true or false. Example: false.
compensationExpected	Boolean [1]	Declares that an unsuccessful process may need business reversal or remediation. The CIM critique then asks for exception scenarios, and the transformation uses those scenarios to create PIM compensation policy and recovery handling. Semantic validation: CompensationProcessHasExceptionScenarios (compensation process has exception scenarios) in mde/validation/cim/rules/process-policy.evl the flag must be enabled for this rule to pass. Transformation role: ETL rule BusinessProcess2Workflow in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining BusinessProcess.	Either true or false. Example: false.
completionCriterion	String [1]	The business-observable condition that makes this process finished, for example, “the reserved order is either confirmed or explicitly rejected.” It is required alongside a trigger so the model describes a complete business lifecycle rather than only an entry point. Semantic validation: ProcessHasTriggerAndCompletionCriterion (process has trigger and completion criterion) in mde/validation/cim/rules/process-policy.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: At least 95% of confirmed orders complete within 2 minutes..
processKind	ProcessKind [1]	Classifies the process pattern, such as a short business process, long-running process, or saga-like process. The classification gives transformations an architectural hint about orchestration and compensation without pretending that a provider-specific workflow type has already been chosen. Semantic validation: LongRunningProcessHasTemporalConstraint (long running process has temporal constraint) in mde/validation/cim/rules/process-policy.evl the flag must be enabled for this rule to pass.	Exactly one of: STRAIGHT_THROUGH, HUMAN_INVOLVED, LONG_RUNNING, CASE_MANAGEMENT, SAGA_LIKE_BUSINESS_PROCESS, REPORTING_PROCESS. Example: STRAIGHT_THROUGH.
criticality	CapabilityCriticality [1]	Expresses the business consequence of this process being unavailable or wrong. The value travels with the process into refinement so resilience, observability, readiness, and production review can be prioritized according to business impact. Transformation role: ETL rule BusinessProcess2Workflow in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining BusinessProcess.	Exactly one of: SUPPORTING, IMPORTANT, CORE, MISSION_CRITICAL. Example: SUPPORTING.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
steps → ProcessStep	containment, [+]	Contains the process step element(s) that make up this business process; the contained objects belong to this model element.
transitions → ProcessTransition	containment, [*]	Contains the process transition element(s) that make up this business process; the contained objects belong to this model element.
exceptions → ExceptionScenario	containment, [*]	Contains the exception scenario element(s) that make up this business process; the contained objects belong to this model element.
temporalConstraints → TemporalConstraint	containment, [*]	Contains the temporal constraint element(s) that make up this business process; the contained objects belong to this model element.
owningCapability → BusinessCapability	reference, [?]; opposite ownsProcesses	References the business capability element(s) used as owning capability by this business process; the target may be shared elsewhere in the model.
triggeringActor → Actor	reference, [?]	References the actor element(s) used as triggering actor by this business process; the target may be shared elsewhere in the model.
triggeringEvent → BusinessEvent	reference, [?]	References the business event element(s) used as triggering event by this business process; the target may be shared elsewhere in the model.
triggeringCommand → Command	reference, [?]	References the command element(s) used as triggering command by this business process; the target may be shared elsewhere in the model.
preconditions → Condition	reference, [*]	References the condition element(s) used as preconditions by this business process; the target may be shared elsewhere in the model.
postconditions → Condition	reference, [*]	References the condition element(s) used as postconditions by this business process; the target may be shared elsewhere in the model.
trigger → ModelElement	reference, [?]	References the model element element(s) used as trigger by this business process; the target may be shared elsewhere in the model.

ProcessStep

The common CIM vocabulary for one meaningful unit of work in a business process. The concrete subtype says whether the unit is a command, query, event, decision, policy, human task, external interaction, wait, start, or end.

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
orderIndex	Integer [1]	The modeller's deterministic position for this step among the steps of one business process. It is a fallback ordering aid, not a replacement for ProcessTransition: CIM EVL checks that supplied indexes are unique, CIM-to-PIM copies the value to the workflow step, and the PIM-to-AWS transformation later sorts workflow steps by it when it must choose a start state or infer an ordered next step. Use distinct non-negative integers such as 0, 1, and 2; use transitions to express branches and loops. Transformation role: ETL rule WaitLikeStep2WorkflowWaitStep in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining ProcessStep. ETL rule ProcessStep2WorkflowTaskStep in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining ProcessStep.	A non-negative integer unique within the process when supplied. Examples: 0, 1, 2. Leave it unset only when explicit transitions fully describe the ordering.
optional	Boolean [1]	Whether the business can legitimately skip the step without treating the process as incomplete. This is different from an implementation-level conditional: it records the business tolerance for omission so PIM workflow design can decide whether to model a branch, a default path, or an explicit review decision.	Either true or false. Example: false.
repeatable	Boolean [1]	Whether the same business step may occur more than once in one process instance, such as retrying an approval or revisiting a validation. It tells refinement that a single linear invocation is not sufficient and that loop, idempotency, or duplicate-side-effect questions must be considered.	Either true or false. Example: false.
responsibility	String [1]	The human-readable responsibility of the step: what outcome the responsible party is expected to produce, not merely a team name. CIM validation requires either this explanation or responsibleRoles; together they give transformation and review enough information to avoid creating an ownerless piece of workflow. Semantic validation: ProcessStepHasResponsibility (process step has responsibility) in mde/validation/cim/rules/process-policy.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: Reserve inventory for a confirmed order..
stepKind	StepKind [1]	The semantic role of the step in the business flow, command, query, event, decision, policy, human task, external interaction, wait, start, or end. The concrete step class and this enum are checked for agreement, and the CIM-to-PIM ETL uses the kind to select the corresponding workflow-step subtype. Semantic validation: ProcessStepHasResponsibility (process step has responsibility) in mde/validation/cim/rules/process-policy.evl the value must satisfy a numeric or ordering boundary.	Exactly one of: COMMAND, QUERY, EVENT, DECISION, POLICY, HUMAN_TASK, EXTERNAL_INTERACTION, WAIT, START, END. Example: COMMAND.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
responsibleRoles → Role	reference, [*]	References the role element(s) used as responsible roles by this process step; the target may be shared elsewhere in the model.

StartStep

The unique business entry point from which the process begins after its trigger has been recognized. It is a process step rather than a diagram-only marker because its position and traceability are carried into workflow generation.

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

Declared attributes

This class declares no attributes of its own. It inherits the attributes of its supertype, if any.

Relationships

This class declares no direct relationships.

EndStep

A business termination point. A process may have more than one end outcome, so an end step gives each successful/failed completion path an explicit place in the process graph.

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

Declared attributes

This class declares no attributes of its own. It inherits the attributes of its supertype, if any.

Relationships

This class declares no direct relationships.

CommandStep

A process unit that changes business state by invoking a modeled CIM command. Keeping the command reference typed lets transformation connect the step to a function/API realization without guessing what the action means.

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

Declared attributes

This class declares no attributes of its own. It inherits the attributes of its supertype, if any.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
command → Command	reference, [1]	References the command element(s) used as command by this command step; the target may be shared elsewhere in the model.

QueryStep

A process unit that obtains information without claiming a state change. The typed query reference preserves the read contract and keeps it distinct from command-side effects.

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

Declared attributes

This class declares no attributes of its own. It inherits the attributes of its supertype, if any.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
query → Query	reference, [1]	References the query element(s) used as query by this query step; the target may be shared elsewhere in the model.

EventStep

A process unit that publishes or reacts to a business event. It represents a domain fact in the process, not simply a message transport operation.

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

Declared attributes

This class declares no attributes of its own. It inherits the attributes of its supertype, if any.

Relationships

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

PolicyStep

A process unit whose behavior is governed by a modeled business policy. It gives policy evaluation a place in the process graph and keeps the policy's rule/decision semantics attached to the flow.

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

Declared attributes

This class declares no attributes of its own. It inherits the attributes of its supertype, if any.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
policy → Policy	reference, [1]	References the policy element(s) used as policy by this policy step; the target may be shared elsewhere in the model.

HumanTaskStep

A process unit that requires a person to perform an action and provide evidence of completion. It is the CIM source for the later human-task, approval, timeout, and escalation design.

Direct supertypes: ProcessStep. 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
taskDescription	String [1]	What a person must actually do, written as an action with a business result rather than as a UI instruction. EVL requires it for a human task, and PIM refinement carries it into HumanTask so assignees, completion evidence, timeouts, and escalation can be designed. Semantic validation: HumanTaskStepKindAndDescription (human task step kind and description) in mde/validation/cim/rules/process-policy.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: Processes confirmed orders for the owning capability..
completionEvidence	String [1]	The evidence that proves the person completed the task, for example, an approval decision, signed document, or recorded review. It prevents a human step from ending on an unverifiable click and becomes the basis for the PIM human-task completion contract. Semantic validation: HumanTaskStepKindAndDescription (human task step kind and description) in mde/validation/cim/rules/process-policy.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: Human Task Step Completion Evidence.

Relationships

This class declares no direct relationships.

ExternalInteractionStep

A process unit that crosses the modeled organization's boundary to exchange information with an external system. Its purpose and exchanged information make the integration a business dependency rather than an unexplained endpoint.

Direct supertypes: ProcessStep. 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
interactionPurpose	String [1]	Why the business process crosses into the named external system. It is required with the system reference because a URL alone does not explain the business dependency; the purpose guides the exchanged-information, contract, resilience, and security decisions in PIM. Semantic validation: ExternalInteractionStepIsExplicit (external interaction step is explicit) in mde/validation/cim/rules/process-policy.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: Reserve inventory for a confirmed order..

Relationships

Relationship	Kind and multiplicity	Meaning in the model
externalSystem → ExternalSystem	reference, [1]	References the external system element(s) used as external system by this external interaction step; the target may be shared elsewhere in the model.
exchangedInformation → InformationItem	reference, [*]	References the information item element(s) used as exchanged information by this external interaction step; the target may be shared elsewhere in the model.

DecisionStep

A branching point whose alternatives are determined by a condition or decision table. The outgoing transitions are part of its semantics; two or more branches are required so it does not masquerade as ordinary work.

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

Declared attributes

This class declares no attributes of its own. It inherits the attributes of its supertype, if any.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
condition → Condition	reference, [?]	References the condition element(s) used as condition by this decision step; the target may be shared elsewhere in the model.
decisionTable → DecisionTable	reference, [?]	References the decision table element(s) used as decision table by this decision step; the target may be shared elsewhere in the model.

WaitStep

A provider-independent pause with either timed or callback/event semantics. Its condition and reason are preserved until the PSM can safely emit an ASL wait state or identify a manual decision.

Direct supertypes: ProcessStep. 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
waitReason	String [1]	Why the workflow is intentionally paused. It preserves the business interpretation of a wait after CIM transformation, helping a modeller choose between a timed wait, callback token, event wait, or a missing transition. Semantic validation: WaitStepHasDurationOrReason (wait step has duration or reason) in mde/validation/cim/rules/process-policy.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: Wait Step Wait Reason.
durationExpression	String [1]	A business-level expression for how long the process waits. The typed durationExpressionModel and this text are carried into PIM temporal policy; the PIM-to-AWS transformation can only emit a concrete Step Functions wait duration when the expression can be interpreted, otherwise it creates a manual decision/readiness finding. Semantic validation: WaitStepHasDurationOrReason (wait step has duration or reason) in mde/validation/cim/rules/process-policy.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'.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
durationExpressionModel → Expression	containment, [?]	Contains the expression element(s) that make up this wait step; the contained objects belong to this model element.

ProcessTransition

A directed business route from one process step to another. Its condition/label explains why the route is taken, while its order index can stabilize competing alternatives without replacing their business predicates.

Direct supertypes: SemanticRelationship. 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
label	String [1]	The business name of the path between two steps, such as inventory available or payment declined. It gives a decision diagram a readable branch meaning; CIM validation requires a label, condition, or condition reference for decision branches. Semantic validation: ConditionalTransitionIsLabelled (conditional transition is labelled) in mde/validation/cim/rules/process-policy.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: Process Transition Label.
conditionExpression	String [1]	The executable or semi-formal predicate that makes this path eligible. CIM-to-PIM resolves the strongest available condition source (conditionRef, this text, or the typed expression) into WorkflowTransition.conditionExpression, which later becomes a workflow/ASL branch condition. Semantic validation: ConditionalTransitionIsLabelled (conditional transition is labelled) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Transformation role: ETL rule ProcessTransition2WorkflowTransition in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining ProcessTransition. ETL rule ProcessTransition2WorkflowTransition in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining ProcessTransition. Generation role: The artifact generator references this feature in mde/generation/awspsm-to-artifacts/lib/contracts.eol.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: $.status == 'READY'.
orderIndex	Integer [1]	The deterministic order of outgoing alternatives when a process author cares about branch precedence or wants stable review output. It does not decide which branch is true, that belongs to the condition, so it should only disambiguate presentation/evaluation order with values such as 0, 1, and 2.	A non-negative integer used only to stabilize the order of outgoing alternatives. Examples: 0, 1. It does not replace the transition condition.
probabilityHint	String [1]	A planning estimate of how often this path is expected to be taken, for example 0.8 or high during peak season. It supports capacity, cost, and risk conversations; it is intentionally a hint and is not used as executable routing logic.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: 0.8.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
condition → Expression	containment, [?]	Contains the expression element(s) that make up this process transition; the contained objects belong to this model element.
source → ProcessStep	reference, [1]	References the process step element(s) used as source by this process transition; the target may be shared elsewhere in the model.
target → ProcessStep	reference, [1]	References the process step element(s) used as target by this process transition; the target may be shared elsewhere in the model.
conditionRef → Condition	reference, [?]	References the condition element(s) used as condition ref by this process transition; the target may be shared elsewhere in the model.

Policy

A reusable business rule that constrains, authorizes, reacts to, or decides something in the CIM. Natural-language and executable forms can coexist so stakeholders can review the intent while transformations preserve machine-checkable behavior.

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
naturalLanguageRule	String [1]	The rule in the vocabulary stakeholders can review, such as “a refund requires an approved return.” It keeps policy intent understandable even when no executable expression exists; CIM validation accepts it as one of the valid rule definitions and transformation can preserve it as policy rationale. Semantic validation: PolicyHasRuleDefinition (policy has rule definition) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Transformation role: ETL rule Policy2PolicyHandlerFunction in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining Policy. ETL rule Policy2PolicyHandlerFunction in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining Policy.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: $.status == 'READY'.
expression	String [1]	The machine-readable form of the policy when the rule must be evaluated rather than merely discussed. expressionLanguage identifies how to parse it and expressionModel can carry the typed form; the distinction lets validation reject a claimed executable policy that has no interpretable expression. Semantic validation: PolicyHasRuleDefinition (policy has rule definition) in mde/validation/cim/rules/process-policy.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'.
auditRequired	Boolean [1]	Whether applying or violating this policy must leave an auditable business record. It is a governance requirement that later influences event, logging, retention, and access-audit design; it is not equivalent to enabling technical logs. Transformation role: ETL rule Policy2PolicyHandlerFunction in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining Policy.	Either true or false. Example: true.
policyType	PolicyType [1]	Identifies the policy's job, constraint, authorization, reaction, decision, or another controlled kind, so consumers know whether it guards an action, responds to an event, or computes an outcome. Semantic validation: ReactionPolicyEmitsOutcome (reaction policy emits outcome) in mde/validation/cim/rules/process-policy.evl the feature participates in a semantic validation condition. Transformation role: ETL rule Policy2PolicyHandlerFunction in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining Policy. ETL rule Policy2ArchitecturePolicy in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining Policy.	Exactly one of: REACTION, GUARD, DERIVATION, AUTHORIZATION, VALIDATION, COMPLIANCE, ESCALATION, COMPENSATION. Example: REACTION.
expressionLanguage	ExpressionLanguage [1]	The language contract for expression, such as FEEL, OCL, JSONPath, or natural language. Without it, the same characters could be interpreted in incompatible ways; with it, validators and transformations can decide whether the expression is suitable for the next model level. Semantic validation: PolicyHasRuleDefinition (policy has rule definition) in mde/validation/cim/rules/process-policy.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.
enforcementStrength	ConstraintStrength [1]	How strongly the organization expects the policy to be enforced: advisory, recommended, mandatory, or blocking. It separates a design preference from a release gate and is why CIM validation demands a violation severity for mandatory or blocking policies. Semantic validation: MandatoryOrBlockingPolicyHasSeverity (mandatory or blocking policy has severity) in mde/validation/cim/rules/process-policy.evl the feature participates in a semantic validation condition. Transformation role: ETL rule Policy2ArchitecturePolicy in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining Policy.	Exactly one of: ADVISORY, RECOMMENDED, MANDATORY, BLOCKING. Example: ADVISORY.
violationSeverity	Severity [1]	The impact assigned when the policy is broken. It lets readiness and transformation tooling distinguish an informational observation from a production-blocking policy failure instead of treating every rule equally. Semantic validation: MandatoryOrBlockingPolicyHasSeverity (mandatory or blocking policy has severity) in mde/validation/cim/rules/process-policy.evl the related value or object must be explicitly provided. Transformation role: ETL rule Policy2PolicyHandlerFunction in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining Policy.	Exactly one of: INFO, WARNING, ERROR, CRITICAL, BLOCKER. Example: INFO.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
expressionModel → Expression	containment, [?]	Contains the expression element(s) that make up this policy; the contained objects belong to this model element.
triggeredBy → BusinessEvent	reference, [*]; opposite consumedByPolicies	References the business event element(s) used as triggered by by this policy; the target may be shared elsewhere in the model.
guards → Command	reference, [*]	References the command element(s) used as guards by this policy; the target may be shared elsewhere in the model.
constrainsQueries → Query	reference, [*]	References the query element(s) used as constrains queries by this policy; the target may be shared elsewhere in the model.
emitsCommands → Command	reference, [*]	References the command element(s) used as emits commands by this policy; the target may be shared elsewhere in the model.
emitsEvents → BusinessEvent	reference, [*]; opposite causedByPolicies	References the business event element(s) used as emits events by this policy; the target may be shared elsewhere in the model.
decisionTable → DecisionTable	reference, [?]	References the decision table element(s) used as decision table by this policy; the target may be shared elsewhere in the model.

DecisionTable

A structured collection of decision rules with an explicit hit policy and default behavior. It makes rule precedence and coverage visible before the decision is converted into a function or workflow choice.

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
hitPolicy	String [1]	The rule-selection strategy for the table, whether the first match, all matches, a unique match, or another result is expected. It determines how overlapping DecisionRule entries are interpreted and must remain explicit before executable decision logic is generated. Semantic validation: DecisionTableRulesHaveUniquePriority (decision table rules have unique priority) in mde/validation/cim/rules/process-policy.evl the feature participates in a semantic validation condition. Transformation role: ETL rule DecisionTable2ChoiceLogic in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining DecisionTable. ETL rule DecisionTable2DecisionModel in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining DecisionTable.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: STANDARD.
defaultOutcome	String [1]	The outcome used when no row matches. An incomplete table must provide it because otherwise a real input can reach the decision with no business answer; EVL checks precisely for that gap. Semantic validation: IncompleteDecisionTableHasDefault (incomplete decision table has default) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Transformation role: ETL rule DecisionTable2DecisionModel in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining DecisionTable. ETL rule DecisionTable2DecisionModel in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining DecisionTable.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: Decision Table Default Outcome.
complete	Boolean [1]	Whether the modeled rules cover the permitted input space. Setting it false is an honest statement that cases remain unmatched, which is why validation asks for a default outcome rather than silently treating the table as total. Semantic validation: IncompleteDecisionTableHasDefault (incomplete decision table has default) in mde/validation/cim/rules/process-policy.evl the flag must be enabled for this rule to pass. Transformation role: ETL rule DecisionTable2ChoiceLogic in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining DecisionTable. ETL rule DecisionTable2DecisionModel in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining DecisionTable. Generation role: The artifact generator references this feature in mde/generation/awspsm-to-artifacts/lib/contracts.eol.	Either true or false. Example: false.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
rules → DecisionRule	containment, [+]	Contains the decision rule element(s) that make up this decision table; the contained objects belong to this model element.
inputs → InformationItem	reference, [*]	References the information item element(s) used as inputs by this decision table; the target may be shared elsewhere in the model.
outputs → InformationItem	reference, [*]	References the information item element(s) used as outputs by this decision table; the target may be shared elsewhere in the model.

DecisionRule

One row of a decision table: a condition, an outcome, and optionally the commands/events caused by that outcome. Priority is modeled separately so overlapping rules can be resolved deliberately.

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
priorityOrder	Integer [1]	The explicit precedence of this row when more than one decision rule could match. EVL checks that supplied priorities are unique; the number therefore expresses business rule ordering, not a database or diagram position.	A numeric Integer value; use the unit or boundary documented for this attribute. Example: 1.
condition	String [1]	The human-readable “when” part of the row. It explains the applicability of the rule to reviewers, while conditionExpression provides the typed/executable representation when the table is refined. Semantic validation: DecisionRuleHasConditionAndOutcome (decision rule has condition and outcome) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Generation role: The artifact generator references this feature in mde/generation/awspsm-to-artifacts/lib/contracts.eol.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: $.status == 'READY'.
outcome	String [1]	The business result produced by a matching row. It gives a decision table a usable answer even before resulting commands/events are linked, and EVL requires either this outcome or an executable outcome expression. Semantic validation: DecisionRuleHasConditionAndOutcome (decision rule has condition and outcome) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. DecisionRuleHasExecutableEffect (decision rule has executable effect) in mde/validation/cim/rules/process-policy.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: Decision Rule Outcome.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
conditionExpression → Expression	containment, [?]	Contains the expression element(s) that make up this decision rule; the contained objects belong to this model element.
outcomeExpression → Expression	containment, [?]	Contains the expression element(s) that make up this decision rule; the contained objects belong to this model element.
resultingCommands → Command	reference, [*]	References the command element(s) used as resulting commands by this decision rule; the target may be shared elsewhere in the model.
resultingEvents → BusinessEvent	reference, [*]	References the business event element(s) used as resulting events by this decision rule; the target may be shared elsewhere in the model.

ExceptionScenario

A business description of a departure from the normal process, including impact, recoverability, recovery action, and compensation need. It is the source of recovery design, not just a catalogue of technical errors.

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
scenario	String [1]	The recognizable business situation in which the normal process cannot continue, such as a payment authorization expiring. It anchors recovery design in a domain event rather than in an arbitrary technical exception name. Semantic validation: ExceptionScenarioIsActionable (exception scenario is actionable) in mde/validation/cim/rules/process-policy.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: Exception Scenario Scenario.
businessImpact	String [1]	What the exception means for the customer, organization, or obligation. It is required because recovery priority cannot be inferred from the exception label alone and it informs compensation/readiness decisions. Semantic validation: ExceptionScenarioIsActionable (exception scenario is actionable) in mde/validation/cim/rules/process-policy.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 delayed fulfillment blocks customer delivery..
expected	Boolean [1]	Whether the scenario is part of normal business variation rather than an exceptional surprise. This distinction changes whether it should be modeled as an ordinary branch or as failure/recovery handling. Transformation role: ETL rule ExceptionScenario2ErrorHandler in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining ExceptionScenario. Generation role: The artifact generator references this feature in mde/generation/awspsm-to-artifacts/templates/tests/contract-test.egl. The artifact generator references this feature in mde/generation/awspsm-to-artifacts/templates/tests/security-test.egl.	Either true or false. Example: false.
recoverable	Boolean [1]	Whether the business believes progress can be restored after this scenario. If true, CIM EVL requires recoveryAction; the flag therefore prevents a recovery path from being implied without an actionable plan. Semantic validation: ExceptionScenarioIsActionable (exception scenario is actionable) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Transformation role: ETL rule ExceptionScenario2ErrorHandler in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining ExceptionScenario.	Either true or false. Example: false.
recoveryAction	String [1]	The business action that restores, compensates, or safely terminates the process after the scenario. The CIM-to-PIM transformation uses it to configure error handling and compensation strategy; it is not just a diagnostic message. Semantic validation: ExceptionScenarioIsActionable (exception scenario is actionable) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. CompensationScenarioEmitsEvent (compensation scenario emits event) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Transformation role: ETL rule ExceptionScenario2ErrorHandler in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining ExceptionScenario. ETL rule ExceptionScenario2ErrorHandler in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining ExceptionScenario.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: Exception Scenario Recovery Action.
compensationRequired	Boolean [1]	Whether recovery must undo a previously committed business effect. When true, EVL expects a recovery action and resulting event, and transformation creates compensation policy/event links so the reversal remains visible in PIM. Semantic validation: CompensationScenarioEmitsEvent (compensation scenario emits event) in mde/validation/cim/rules/process-policy.evl the flag must be enabled for this rule to pass.	Either true or false. Example: true.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
errors → BusinessError	reference, [*]	References the business error element(s) used as errors by this exception scenario; the target may be shared elsewhere in the model.
resultingEvents → BusinessEvent	reference, [*]	References the business event element(s) used as resulting events by this exception scenario; the target may be shared elsewhere in the model.

TemporalConstraint

A timing or ordering rule applied to selected process elements. It captures deadlines, durations, and precedence before the transformation attempts to turn them into PIM timeout/schedule policies or AWS wait settings.

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
deadlineExpression	String [1]	The latest acceptable point by which the constrained business element must finish. It captures a deadline rather than a per-step runtime timeout; CIM-to-PIM converts parseable forms into timeout policy and records a manual decision when it cannot derive seconds. Semantic validation: TemporalConstraintHasExpression (temporal constraint has expression) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Transformation role: ETL rule TemporalConstraint2TimeoutPolicy in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining TemporalConstraint. ETL rule TemporalConstraint2TimeoutPolicy in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining TemporalConstraint.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: $.status == 'READY'.
durationExpression	String [1]	The allowed elapsed time for the constrained process, step, or event. It is the source for provider-independent timeout expectations and, when parseable, Workflow.expectedMaxDurationSeconds or WorkflowStep.timeoutSeconds. Semantic validation: TemporalConstraintHasExpression (temporal constraint has expression) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Transformation role: ETL rule TemporalConstraint2TimeoutPolicy in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining TemporalConstraint.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: $.status == 'READY'.
orderingExpression	String [1]	A temporal relationship such as “approval must precede shipment” or “event B follows event A.” It expresses ordering that a numeric duration cannot capture and gives transformation/review a reason to preserve a dependency between model elements. Semantic validation: TemporalConstraintHasExpression (temporal constraint has expression) in mde/validation/cim/rules/process-policy.evl the value must be present and non-blank. Transformation role: ETL rule TemporalConstraint2TimeoutPolicy in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining TemporalConstraint. ETL rule TemporalConstraint2TimeoutPolicy in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining TemporalConstraint.	A free-form String, subject to this class's semantic meaning and any EVL constraints. Example: $.status == 'READY'.
violationSeverity	Severity [1]	The consequence of missing the time rule. A blocker-level temporal violation becomes a production-readiness concern during transformation, while a warning can remain a review item. Transformation role: ETL rule TemporalConstraint2TimeoutPolicy in mde/transformations/cim-to-pim/process-policy.etl assigns or materializes this feature while refining TemporalConstraint. ETL rule TemporalConstraint2TimeoutPolicy in mde/transformations/cim-to-pim/process-policy.etl reads or derives this feature while refining TemporalConstraint.	Exactly one of: INFO, WARNING, ERROR, CRITICAL, BLOCKER. Example: INFO.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
deadline → Expression	containment, [?]	Contains the expression element(s) that make up this temporal constraint; the contained objects belong to this model element.
duration → Expression	containment, [?]	Contains the expression element(s) that make up this temporal constraint; the contained objects belong to this model element.
ordering → Expression	containment, [?]	Contains the expression element(s) that make up this temporal constraint; the contained objects belong to this model element.
constrainedElements → ModelElement	reference, [*]	References the model element element(s) used as constrained elements by this temporal constraint; the target may be shared elsewhere in the model.