Quality, security, privacy, and compliance

Governance elements turn quality, privacy, security, and regulatory expectations into model facts that can constrain later design.

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

`NonFunctionalRequirement`

Represents non functional requirement in the CIM vocabulary. It specializes Requirement with the details needed for this modeling concern.

Direct supertypes: Requirement. 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
`metric`	`String` [1]	Records the metric value for the non functional requirement. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `NFRMustBeMeasurable` (nfrmust be measurable) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `AvailabilityReliabilityNfr2ResiliencePolicy` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `NonFunctionalRequirement`. ETL rule `PerformanceNfr2TimeoutPolicy` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `NonFunctionalRequirement`. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/templates/docs/operations.egl`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Non Functional Requirement Metric`.
`target`	`String` [1]	Stores the destination selected for target on the non functional requirement. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `NFRMustBeMeasurable` (nfrmust be measurable) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `AvailabilityReliabilityNfr2ResiliencePolicy` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `NonFunctionalRequirement`. ETL rule `PerformanceNfr2TimeoutPolicy` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `NonFunctionalRequirement`. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/awspsm2artifacts.egx`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Non Functional Requirement Target`.
`measurementMethod`	`String` [1]	Stores the measurement method value on the non functional requirement. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Transformation role: ETL rule `AuditOperabilityNfr2Observability` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `NonFunctionalRequirement`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Non Functional Requirement Measurement Method`.
`environmentAssumption`	`String` [1]	Records the environment assumption value for the non functional requirement. 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.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Non Functional Requirement Environment Assumption`.
`qualityType`	`QualityType` [1]	Stores the controlled classification or strategy represented by quality type on the non functional requirement. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Transformation role: ETL rule `AvailabilityReliabilityNfr2ResiliencePolicy` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `NonFunctionalRequirement`. ETL rule `PerformanceNfr2TimeoutPolicy` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `NonFunctionalRequirement`.	Exactly one of: `PERFORMANCE`, `LATENCY`, `AVAILABILITY`, `RELIABILITY`, `SCALABILITY`, `SECURITY`, `PRIVACY`, `AUDITABILITY`, `MAINTAINABILITY`, `OPERABILITY`, `COST`, `DATA_QUALITY`, `COMPLIANCE`, `USABILITY`. Example: `PERFORMANCE`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`scenarios` → `QualityScenario`	containment, [*]	Contains the quality scenario element(s) that make up this non functional requirement; the contained objects belong to this model element.
`constrainedElements` → `ModelElement`	reference, [+]	References the model element element(s) used as constrained elements by this non functional requirement; the target may be shared elsewhere in the model.

`QualityScenario`

Represents quality scenario 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
`source`	`String` [1]	Stores the origin/source selected for source on the quality scenario. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `QualityScenarioIsComplete` (quality scenario is complete) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`. 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: `Quality Scenario Source`.
`stimulus`	`String` [1]	Records the stimulus value for the quality scenario. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `QualityScenarioIsComplete` (quality scenario is complete) 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: `Quality Scenario Stimulus`.
`environment`	`String` [1]	Stores the environment value on the quality scenario. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `QualityScenarioIsComplete` (quality scenario is complete) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/templates/cicd/github-actions-deploy-dev.egl`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Quality Scenario Environment`.
`artifact`	`String` [1]	Records the artifact value for the quality scenario. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `QualityScenarioIsComplete` (quality scenario is complete) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/awspsm2artifacts.egx`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/trace.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Quality Scenario Artifact`.
`response`	`String` [1]	For a quality scenario, the model records the response value. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `QualityScenarioIsComplete` (quality scenario is complete) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/awspsm2artifacts.egx`. 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: `Quality Scenario Response`.
`responseMeasure`	`String` [1]	Stores the response measure value on the quality scenario. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `QualityScenarioIsComplete` (quality scenario is complete) 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: `Quality Scenario Response Measure`.
`qualityType`	`QualityType` [1]	For a quality scenario, the model records the controlled classification or strategy represented by quality type. 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.	Exactly one of: `PERFORMANCE`, `LATENCY`, `AVAILABILITY`, `RELIABILITY`, `SCALABILITY`, `SECURITY`, `PRIVACY`, `AUDITABILITY`, `MAINTAINABILITY`, `OPERABILITY`, `COST`, `DATA_QUALITY`, `COMPLIANCE`, `USABILITY`. Example: `PERFORMANCE`.

Relationships

This class declares no direct relationships.

`SecurityConstraint`

Represents security constraint in the CIM vocabulary. It specializes NonFunctionalRequirement with the details needed for this modeling concern.

Direct supertypes: NonFunctionalRequirement. 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
`authenticationNeed`	`String` [1]	Records the authentication need value for security constraint. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `SecurityConstraintHasRuleOrThreatRationale` (security constraint has rule or threat rationale) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Security Constraint Authentication Need`.
`authorizationRule`	`String` [1]	Stores the expression or rule that governs authorization rule on the security constraint. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `SecurityConstraintHasRuleOrThreatRationale` (security constraint has rule or threat rationale) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. `SecurityConstraintAlignsCommandAuthorization` (security constraint aligns command authorization) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityConstraint`. ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` reads or derives this feature while refining `SecurityConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`segregationOfDutiesRequired`	`Boolean` [1]	Records whether segregation of duties required applies to security constraint. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityConstraint`.	Either `true` or `false`. Example: `true`.
`nonRepudiationRequired`	`Boolean` [1]	Records whether non repudiation required applies to security constraint. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityConstraint`.	Either `true` or `false`. Example: `true`.
`auditAccessRequired`	`Boolean` [1]	Records whether audit access required applies to security constraint. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityConstraint`.	Either `true` or `false`. Example: `true`.
`threatRationale`	`String` [1]	For a security constraint, the model records the reasoning behind threat rationale. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `SecurityConstraintHasRuleOrThreatRationale` (security constraint has rule or threat rationale) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `SecurityConstraint2SecurityPolicies` in `mde/transformations/cim-to-pim/process-policy.etl` assigns or materializes this feature while refining `SecurityConstraint`.	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
`constrainedActors` → `Actor`	reference, [*]	References the actor element(s) used as constrained actors by this security constraint; the target may be shared elsewhere in the model.
`constrainedCommands` → `Command`	reference, [*]	References the command element(s) used as constrained commands by this security constraint; the target may be shared elsewhere in the model.
`constrainedQueries` → `Query`	reference, [*]	References the query element(s) used as constrained queries by this security constraint; the target may be shared elsewhere in the model.
`constrainedInformation` → `InformationItem`	reference, [*]	References the information item element(s) used as constrained information by this security constraint; the target may be shared elsewhere in the model.

`PrivacyConstraint`

Represents privacy constraint in the CIM vocabulary. It specializes NonFunctionalRequirement with the details needed for this modeling concern.

Direct supertypes: NonFunctionalRequirement. 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
`law`	`String` [1]	Records the law value for the privacy constraint. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `PrivacyConstraint2Policies` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `PrivacyConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Privacy Constraint Law`.
`jurisdiction`	`String` [1]	Stores the jurisdiction value on the privacy constraint. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `DataResidencyHasAllowedArea` (data residency has allowed area) in `mde/validation/cim/rules/governance-readiness.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `PrivacyConstraint2Policies` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `PrivacyConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Privacy Constraint Jurisdiction`.
`dataSubjectType`	`String` [1]	Records the controlled classification or strategy for data subject type in the privacy constraint. 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.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `BUSINESS`.
`purpose`	`String` [1]	Records human explanation of purpose for privacy constraint. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `PrivacyNeedsPurposeAndLegalBasis` (privacy needs purpose and legal basis) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `PrivacyConstraint2Policies` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `PrivacyConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Reserve inventory for a confirmed order.`.
`retentionPeriod`	`String` [1]	Stores the data-lifecycle rule for retention period on the privacy constraint. The field records retention and data-lifecycle controls as an explicit, reviewable input. Semantic validation: `PrivacyConstraintHasRetentionOrMinimization` (privacy constraint has retention or minimization) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `PrivacyConstraint2Policies` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `PrivacyConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Privacy Constraint Retention Period`.
`consentRequired`	`Boolean` [1]	Records whether consent required applies to privacy constraint. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `ConsentBasisRequiresConsent` (consent basis requires consent) in `mde/validation/cim/rules/governance-readiness.evl` the flag must be enabled for this rule to pass.	Either `true` or `false`. Example: `true`.
`deletionRequired`	`Boolean` [1]	For a privacy constraint, the model records the data-lifecycle rule for deletion required. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Transformation role: ETL rule `PrivacyConstraint2Policies` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `PrivacyConstraint`.	Either `true` or `false`. Example: `true`.
`portabilityRequired`	`Boolean` [1]	Records whether portability required applies to privacy constraint. 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: `true`.
`rectificationRequired`	`Boolean` [1]	For a privacy constraint, the model records whether rectification required 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`.
`dataResidencyRequired`	`Boolean` [1]	For a privacy constraint, the model records whether data residency required applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `DataResidencyHasAllowedArea` (data residency has allowed area) in `mde/validation/cim/rules/governance-readiness.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `PrivacyConstraint2Policies` in `mde/transformations/cim-to-pim/domain-data.etl` reads or derives this feature while refining `PrivacyConstraint`.	Either `true` or `false`. Example: `true`.
`allowedResidencyArea`	`String` [1]	Stores the allowed residency area value on the privacy constraint. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `DataResidencyHasAllowedArea` (data residency has allowed area) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `PrivacyConstraint2Policies` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `PrivacyConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Privacy Constraint Allowed Residency Area`.
`crossBorderTransferAllowed`	`Boolean` [1]	For a privacy constraint, the model records the precedence value for cross border transfer allowed. 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`.
`minimizationRule`	`String` [1]	Records the expression or rule that governs minimization rule for the privacy constraint. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `PrivacyConstraintHasRetentionOrMinimization` (privacy constraint has retention or minimization) 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: `$.status == 'READY'`.
`legalBasis`	`LegalBasis` [1]	Stores the controlled classification or strategy represented by legal basis on the privacy constraint. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `PrivacyNeedsPurposeAndLegalBasis` (privacy needs purpose and legal basis) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. `ConsentBasisRequiresConsent` (consent basis requires consent) in `mde/validation/cim/rules/governance-readiness.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `PrivacyConstraint2Policies` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `PrivacyConstraint`.	Exactly one of: `CONSENT`, `CONTRACT`, `LEGAL_OBLIGATION`, `VITAL_INTERESTS`, `PUBLIC_TASK`, `LEGITIMATE_INTEREST`, `NOT_APPLICABLE`, `UNKNOWN`. Example: `CONSENT`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`dataItems` → `InformationItem`	reference, [+]; opposite `privacyConstraints`	References the information item element(s) used as data items by this privacy constraint; the target may be shared elsewhere in the model.
`dataSubjects` → `Actor`	reference, [*]	References the actor element(s) used as data subjects by this privacy constraint; the target may be shared elsewhere in the model.

`ComplianceConstraint`

Represents compliance constraint in the CIM vocabulary. It specializes NonFunctionalRequirement with the details needed for this modeling concern.

Direct supertypes: NonFunctionalRequirement. 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
`regulation`	`String` [1]	Stores the regulation value on the compliance constraint. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `ComplianceConstraintIsAuditable` (compliance constraint is auditable) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `ComplianceConstraint2CompliancePolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `ComplianceConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Compliance Constraint Regulation`.
`controlId`	`String` [1]	Stores the stable name/key/code used for control id on the compliance constraint. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `ComplianceConstraintIsAuditable` (compliance constraint is auditable) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `ComplianceConstraint2CompliancePolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `ComplianceConstraint`. ETL rule `ComplianceConstraint2CompliancePolicy` in `mde/transformations/cim-to-pim/domain-data.etl` reads or derives this feature while refining `ComplianceConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `order-123`.
`controlObjective`	`String` [1]	For a compliance constraint, the model records the control objective value. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `ComplianceConstraintIsAuditable` (compliance constraint is auditable) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `ComplianceConstraint2CompliancePolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `ComplianceConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Compliance Constraint Control Objective`.
`evidenceRequired`	`String` [1]	For a compliance constraint, the model records whether evidence required applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `ComplianceConstraintIsAuditable` (compliance constraint is auditable) in `mde/validation/cim/rules/governance-readiness.evl` the value must be present and non-blank. Transformation role: ETL rule `ComplianceConstraint2CompliancePolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `ComplianceConstraint`. ETL rule `ComplianceConstraint2CompliancePolicy` in `mde/transformations/cim-to-pim/domain-data.etl` reads or derives this feature while refining `ComplianceConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Compliance Constraint Evidence Required`.
`auditFrequency`	`String` [1]	Records the audit frequency value for compliance constraint. It keeps this decision explicit during 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.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `PT5M`.
`externalAuditRequired`	`Boolean` [1]	Records whether external audit required applies to compliance constraint. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `ComplianceConstraint2CompliancePolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `ComplianceConstraint`.	Either `true` or `false`. Example: `true`.

Relationships

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