Transformation assumptions and readiness signals

Transformation metadata records uncertainty and decisions at the business boundary so generated PIM elements remain explainable.

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

`Risk`

Represents risk 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
`riskStatement`	`String` [1]	Records the risk statement value for the risk. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `RiskIsActionableWhenBlocking` (risk is actionable when blocking) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `Risk2ReadinessFinding` in `mde/transformations/cim-to-pim/integration-deployment.etl` assigns or materializes this feature while refining `Risk`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `ACTIVE`.
`probability`	`String` [1]	Stores the likelihood estimate for the process on the risk. The field records risk and prioritisation review as an explicit, reviewable input. Semantic validation: `RiskIsActionableWhenBlocking` (risk is actionable when blocking) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `Risk2ReadinessFinding` in `mde/transformations/cim-to-pim/integration-deployment.etl` assigns or materializes this feature while refining `Risk`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `0.8`.
`impact`	`String` [1]	Records the consequence assessment represented by impact for the risk. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `RiskIsActionableWhenBlocking` (risk is actionable when blocking) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `Risk2ReadinessFinding` in `mde/transformations/cim-to-pim/integration-deployment.etl` assigns or materializes this feature while refining `Risk`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `A delayed fulfillment blocks customer delivery.`.
`mitigation`	`String` [1]	Stores the mitigation value on the risk. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `RiskIsActionableWhenBlocking` (risk is actionable when blocking) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `Risk2ReadinessFinding` in `mde/transformations/cim-to-pim/integration-deployment.etl` assigns or materializes this feature while refining `Risk`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Risk Mitigation`.
`productionBlocking`	`Boolean` [1]	Records whether production blocking applies to risk. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `RiskIsActionableWhenBlocking` (risk is actionable when blocking) in `mde/validation/cim/rules/governance-readiness.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `Risk2ReadinessFinding` in `mde/transformations/cim-to-pim/integration-deployment.etl` reads or derives this feature while refining `Risk`. ETL rule `Risk2ReadinessFinding` in `mde/transformations/cim-to-pim/integration-deployment.etl` assigns or materializes this feature while refining `Risk`.	Either `true` or `false`. Example: `true`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`affectedElements` → `ModelElement`	reference, [*]	References the model element element(s) used as affected elements by this risk; the target may be shared elsewhere in the model.

`Assumption`

Represents assumption in the CIM vocabulary. It specializes TransformationAssumption with the details needed for this modeling concern.

Direct supertypes: TransformationAssumption. 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
`businessArea`	`String` [1]	For a assumption, the model records the business area value. 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.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Assumption Business Area`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`affectedElements` → `ModelElement`	reference, [*]	References the model element element(s) used as affected elements by this assumption; the target may be shared elsewhere in the model.

`Hotspot`

Represents hotspot 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
`question`	`String` [1]	Records the question value for hotspot. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `BlockingHotspotRequiresOwner` (blocking hotspot requires owner) in `mde/validation/cim/rules/governance-readiness.evl` the feature participates in a semantic validation condition. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/validation.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Hotspot Question`.
`impact`	`String` [1]	Records the consequence assessment represented by impact for the hotspot. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `BlockingHotspotRequiresOwner` (blocking hotspot requires owner) in `mde/validation/cim/rules/governance-readiness.evl` the feature participates in a semantic validation condition. `BlockingHotspotHasDueDateAndImpact` (blocking hotspot has due date and impact) in `mde/validation/cim/rules/governance-readiness.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.`.
`owner`	`String` [1]	For a hotspot, the model records the accountable person, team, or identity for owner. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `BlockingHotspotRequiresOwner` (blocking hotspot requires owner) in `mde/validation/cim/rules/governance-readiness.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: `orders-team`.
`dueDate`	`Date` [1]	Records the due date value for hotspot. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `BlockingHotspotHasDueDateAndImpact` (blocking hotspot has due date and impact) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank.	A `Date` value. Example: `2026-01-15`.
`blocksTransformation`	`Boolean` [1]	Records whether blocks transformation applies to hotspot. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `BlockingHotspotRequiresOwner` (blocking hotspot requires owner) in `mde/validation/cim/rules/governance-readiness.evl` the flag must be enabled for this rule to pass. `BlockingHotspotHasDueDateAndImpact` (blocking hotspot has due date and impact) in `mde/validation/cim/rules/governance-readiness.evl` the flag must be enabled for this rule to pass.	Either `true` or `false`. Example: `false`.
`blocksProduction`	`Boolean` [1]	Records whether blocks production applies to hotspot. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `BlockingHotspotRequiresOwner` (blocking hotspot requires owner) in `mde/validation/cim/rules/governance-readiness.evl` the flag must be enabled for this rule to pass. `BlockingHotspotHasDueDateAndImpact` (blocking hotspot has due date and impact) in `mde/validation/cim/rules/governance-readiness.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
`attachedTo` → `ModelElement`	reference, [*]	References the model element element(s) used as attached to by this hotspot; the target may be shared elsewhere in the model.

`TransformationProfile`

Represents transformation profile 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
`preferCapabilityAsServiceBoundary`	`Boolean` [1]	Records the boundary within which prefer capability as service boundary is interpreted for the transformation profile. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `ServiceGranularityPreferenceHasRationale` (service granularity preference has rationale) in `mde/validation/cim/rules/governance-readiness.evl` the flag must be enabled for this rule to pass.	Either `true` or `false`. Example: `false`.
`preferProcessAsWorkflowCandidate`	`Boolean` [1]	Records whether prefer process as workflow candidate applies to transformation profile. This keeps the decision explicit even when the element's class or relationships remain unchanged. 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: `false`.
`preferEventDrivenCollaboration`	`Boolean` [1]	Records whether prefer event driven collaboration applies to transformation profile. This keeps the decision explicit even when the element's class or relationships remain unchanged. 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: `false`.
`requireExplicitActorAuthForCommands`	`Boolean` [1]	Records whether require explicit actor auth for commands applies to transformation profile. This keeps the decision explicit even when the element's class or relationships remain unchanged. 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: `false`.
`requirePrivacyClassificationForAllInformation`	`Boolean` [1]	Records the data-sensitivity classification for require privacy classification in all information in transformation profile. It keeps privacy, encryption, and access decisions explicit during review and transformation, so later steps do not have to infer them. 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: `false`.
`generateReadModelsFromQueries`	`Boolean` [1]	Records whether generate read models from queries applies to transformation profile. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. 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: `false`.
`defaultServiceGranularityRationale`	`String` [1]	Records the reasoning behind default service granularity rationale for the transformation profile. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `ServiceGranularityPreferenceHasRationale` (service granularity preference has rationale) in `mde/validation/cim/rules/governance-readiness.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.`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`requiredDecisions` → `ManualDecision`	reference, [*]	References the manual decision element(s) used as required decisions by this transformation profile; the target may be shared elsewhere in the model.