Domain concepts and information

Use this module to describe business concepts and information before choosing persistence or implementation technology.

Source: mde/metamodels/cim/cim-domain-data.emf.

`DomainConcept`

An abstract domain concept concept. Use one of its concrete subtypes when creating a model instance; the shared attributes and relationships defined here still apply.

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
`glossaryDefinition`	`String` [1]	Records human explanation of glossary definition for domain concept. It keeps human review and generated guidance explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `DomainConceptHasBusinessDefinition` (domain concept has business definition) in `mde/validation/cim/rules/domain-data.evl` the value must be present and non-blank.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `A confirmed order is one accepted for fulfillment by the business.`.
`examples`	`String` [1]	Records the examples value for the domain concept. 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: `Domain Concept Examples`.
`businessOwner`	`String` [1]	Records the accountable person, team, or identity for business owner for the domain concept. 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: `orders-team`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`outgoingRelationships` → `DomainRelationship`	reference, [*]; opposite `source`	References the domain relationship element(s) used as outgoing relationships by this domain concept; the target may be shared elsewhere in the model.
`incomingRelationships` → `DomainRelationship`	reference, [*]; opposite `target`	References the domain relationship element(s) used as incoming relationships by this domain concept; the target may be shared elsewhere in the model.

`DomainEntity`

Represents domain entity in the CIM vocabulary. It specializes DomainConcept with the details needed for this modeling concern.

Direct supertypes: DomainConcept. 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
`identityDescription`	`String` [1]	How the business recognizes the same entity over time. It complements the identity strategy with human meaning that cannot be inferred from a key field alone.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Processes confirmed orders for the owning capability.`.
`lifecycleDescription`	`String` [1]	The business story of creation, change, and retirement for the entity. It gives lifecycle states and process transitions a domain explanation.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Processes confirmed orders for the owning capability.`.
`auditRelevant`	`Boolean` [1]	Whether changes or access to this entity matter as an audit trail. The flag helps later policy and storage design distinguish ordinary data from accountable business history.	Either `true` or `false`. Example: `true`.
`identityStrategy`	`IdentityStrategy` [1]	The business identity approach, natural, composite, surrogate, external, or unknown, that guides PIM key design without prematurely choosing a database implementation.	Exactly one of: `NATURAL_KEY`, `COMPOSITE_NATURAL_KEY`, `SURROGATE_KEY`, `EXTERNAL_REFERENCE`, `UNKNOWN`. Example: `NATURAL_KEY`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`lifecycleStates` → `LifecycleStateDefinition`	containment, [*]	Contains the lifecycle state definition element(s) that make up this domain entity; the contained objects belong to this model element.
`invariants` → `BusinessInvariant`	containment, [*]	Contains the business invariant element(s) that make up this domain entity; the contained objects belong to this model element.
`identityAttributes` → `InformationItem`	reference, [+]	References the information item element(s) used as identity attributes by this domain entity; the target may be shared elsewhere in the model.
`primaryIdentityAttribute` → `InformationItem`	reference, [1]	References the information item element(s) used as primary identity attribute by this domain entity; the target may be shared elsewhere in the model.
`attributes` → `InformationItem`	reference, [*]	References the information item element(s) used as attributes by this domain entity; the target may be shared elsewhere in the model.
`owningCapability` → `BusinessCapability`	reference, [?]; opposite `managesEntities`	References the business capability element(s) used as owning capability by this domain entity; the target may be shared elsewhere in the model.

`ValueObject`

Represents value object in the CIM vocabulary. It specializes DomainConcept with the details needed for this modeling concern.

Direct supertypes: DomainConcept. 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
`valueType`	`PrimitiveBusinessType` [1]	Records the controlled classification or strategy for value type in the value object. 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.	Exactly one of: `TEXT`, `NUMBER`, `INTEGER`, `DECIMAL`, `BOOLEAN`, `DATE`, `TIME`, `DATETIME`, `MONEY`, `EMAIL`, `PHONE`, `ADDRESS`, `IDENTIFIER`, `ENUMERATION`, `OBJECT`, `LIST`, `DOCUMENT`, `BINARY`. Example: `TEXT`.
`immutable`	`Boolean` [1]	For a value object, the model records whether immutable applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `ValueObjectShouldBeImmutable` (value object should be immutable) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass.	Either `true` or `false`. Example: `false`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`attributes` → `InformationItem`	reference, [*]	References the information item element(s) used as attributes by this value object; the target may be shared elsewhere in the model.
`equalityAttributes` → `InformationItem`	reference, [*]	References the information item element(s) used as equality attributes by this value object; the target may be shared elsewhere in the model.

`DomainRelationship`

Represents domain relationship in the CIM vocabulary. It specializes SemanticRelationship with the details needed for this modeling concern.

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
`sourceRole`	`String` [1]	The name of the source concept's role in the relationship, making the direction readable in domain language rather than relying on class names. Semantic validation: `DomainRelationshipHasRolesAndMultiplicities` (domain relationship has roles and multiplicities) in `mde/validation/cim/rules/domain-data.evl` the value must be present and non-blank. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DomainRelationship`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `order-manager`.
`targetRole`	`String` [1]	The target concept's role as understood by the business. Together with sourceRole it prevents an association from losing its meaning during schema transformation. Semantic validation: `DomainRelationshipHasRolesAndMultiplicities` (domain relationship has roles and multiplicities) in `mde/validation/cim/rules/domain-data.evl` the value must be present and non-blank. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` reads or derives this feature while refining `DomainRelationship`. ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DomainRelationship`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `order-manager`.
`ownership`	`Boolean` [1]	Whether the source concept owns the target concept's lifecycle. This is stronger than navigability and can affect composition, deletion, and persistence boundaries. Semantic validation: `DomainRelationshipHasRolesAndMultiplicities` (domain relationship has roles and multiplicities) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. `OwnershipRelationshipUsesOwnershipType` (ownership relationship uses ownership type) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/templates/docs/operations.egl`.	Either `true` or `false`. Example: `false`.
`navigableFromSource`	`Boolean` [1]	Whether users of the source concept need to traverse to the target. It records access intent separately from ownership and avoids generating unnecessary data joins or references. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DomainRelationship`.	Either `true` or `false`. Example: `false`.
`navigableFromTarget`	`Boolean` [1]	Whether traversal in the reverse direction is part of the domain use case. The asymmetry is important when the relationship is not a bidirectional query requirement.	Either `true` or `false`. Example: `false`.
`relationshipType`	`DomainRelationshipType` [1]	The semantic kind of connection, association, composition, aggregation, generalization, dependency, or ownership, that later models use to choose a safe structural representation. Semantic validation: `OwnershipRelationshipUsesOwnershipType` (ownership relationship uses ownership type) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DomainRelationship`.	Exactly one of: `ASSOCIATION`, `COMPOSITION`, `AGGREGATION`, `GENERALIZATION`, `DEPENDENCY`, `OWNERSHIP`. Example: `ASSOCIATION`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`sourceMultiplicity` → `Multiplicity`	containment, [1]	Contains the multiplicity element(s) that make up this domain relationship; the contained objects belong to this model element.
`targetMultiplicity` → `Multiplicity`	containment, [1]	Contains the multiplicity element(s) that make up this domain relationship; the contained objects belong to this model element.
`source` → `DomainConcept`	reference, [1]; opposite `outgoingRelationships`	References the domain concept element(s) used as source by this domain relationship; the target may be shared elsewhere in the model.
`target` → `DomainConcept`	reference, [1]; opposite `incomingRelationships`	References the domain concept element(s) used as target by this domain relationship; the target may be shared elsewhere in the model.

`AggregateCandidate`

Represents aggregate candidate in the CIM vocabulary. It specializes DomainConcept with the details needed for this modeling concern.

Direct supertypes: DomainConcept. 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
`consistencyBoundaryRationale`	`String` [1]	Why these concepts must change under one consistency boundary. It is the argument that turns an entity grouping into an aggregate candidate rather than a visual cluster. Semantic validation: `StrongConsistencyRequiresRationale` (strong consistency requires rationale) in `mde/validation/cim/rules/domain-data.evl` the value must be present and non-blank. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` reads or derives this feature while refining `AggregateCandidate`.	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.`.
`conflictResolutionPolicy`	`String` [1]	What the business wants when concurrent changes conflict. This is essential input for idempotency, optimistic concurrency, retries, and manual reconciliation. Semantic validation: `EventualConsistencyHasConflictPolicy` (eventual consistency has conflict policy) in `mde/validation/cim/rules/domain-data.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: `STANDARD`.
`idempotencyBusinessKey`	`String` [1]	The business key that lets a repeated command be recognized as the same intent. It is the bridge from duplicate-submission risk in CIM to an idempotency policy in PIM. Semantic validation: `AggregateCommandsDeclareIdempotency` (aggregate commands declare idempotency) in `mde/validation/cim/rules/domain-data.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: `orderId`.
`strongConsistencyRequired`	`Boolean` [1]	Whether invariants require immediate agreement across the aggregate. It prevents an eventually consistent implementation from being selected where business correctness requires atomic visibility. Semantic validation: `StrongConsistencyRequiresRationale` (strong consistency requires rationale) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass. `StrongConsistencyExpectationIsConsistent` (strong consistency expectation is consistent) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` reads or derives this feature while refining `AggregateCandidate`.	Either `true` or `false`. Example: `true`.
`consistencyExpectation`	`ConsistencyExpectation` [1]	The acceptable consistency contract for the aggregate, including whether eventual consistency or manual reconciliation is acceptable. Semantic validation: `StrongConsistencyExpectationIsConsistent` (strong consistency expectation is consistent) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. `EventualConsistencyHasConflictPolicy` (eventual consistency has conflict policy) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `AggregateCandidate`.	Exactly one of: `SINGLE_ENTITY`, `MULTI_ENTITY_STRONG_CONSISTENCY`, `EVENTUAL_CONSISTENCY_ACCEPTABLE`, `MANUAL_RECONCILIATION_ACCEPTABLE`. Example: `SINGLE_ENTITY`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`invariants` → `BusinessInvariant`	containment, [*]	Contains the business invariant element(s) that make up this aggregate candidate; the contained objects belong to this model element.
`root` → `DomainEntity`	reference, [1]	References the domain entity element(s) used as root by this aggregate candidate; the target may be shared elsewhere in the model.
`members` → `DomainEntity`	reference, [+]	References the domain entity element(s) used as members by this aggregate candidate; the target may be shared elsewhere in the model.
`context` → `BoundedContextCandidate`	reference, [?]	References the bounded context candidate element(s) used as context by this aggregate candidate; the target may be shared elsewhere in the model.
`handledCommands` → `Command`	reference, [*]	References the command element(s) used as handled commands by this aggregate candidate; the target may be shared elsewhere in the model.
`emittedEvents` → `BusinessEvent`	reference, [*]	References the business event element(s) used as emitted events by this aggregate candidate; the target may be shared elsewhere in the model.

`LifecycleStateDefinition`

Represents lifecycle state definition 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
`stateName`	`String` [1]	For a lifecycle state definition, the model records the stable name/key/code used for state name. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/contracts.eol`. 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: `ACTIVE`.
`initial`	`Boolean` [1]	For a lifecycle state definition, the model records whether initial 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: `false`.
`terminal`	`Boolean` [1]	Records whether terminal applies to lifecycle state definition. The field records an explicit architectural or governance decision as an explicit, reviewable input. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	Either `true` or `false`. Example: `false`.
`entryCondition`	`String` [1]	Records the expression or rule that governs entry condition for the lifecycle state definition. 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: `$.status == 'READY'`.
`exitCondition`	`String` [1]	Records the expression or rule that governs exit condition for the lifecycle state definition. 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: `$.status == 'READY'`.

Relationships

This class declares no direct relationships.

`BusinessInvariant`

Represents business invariant 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
`naturalLanguageStatement`	`String` [1]	For a business invariant, the model records the natural language statement value. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `BusinessInvariantIsExpressed` (business invariant is expressed) in `mde/validation/cim/rules/domain-data.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: `ACTIVE`.
`expression`	`String` [1]	For a business invariant, the model records the expression or rule that governs expression. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `BusinessInvariantIsExpressed` (business invariant is expressed) in `mde/validation/cim/rules/domain-data.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'`.
`violationSeverity`	`Severity` [1]	For a business invariant, the model records the controlled classification or strategy represented by violation severity. 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: `INFO`, `WARNING`, `ERROR`, `CRITICAL`, `BLOCKER`. Example: `INFO`.
`expressionLanguage`	`ExpressionLanguage` [1]	For a business invariant, the model records the controlled classification or strategy represented by expression language. 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: `NATURAL_LANGUAGE`, `OCL`, `FEEL`, `JSONPATH`, `JSONATA`, `JAVASCRIPT`, `TYPESCRIPT`, `PYTHON`, `SQL`, `REGEX`, `OTHER`. Example: `NATURAL_LANGUAGE`.

Relationships

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

`InformationItem`

Represents information item 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
`businessName`	`String` [1]	The domain-facing name of the information, distinct from a generated field name. It keeps schemas and storage designs understandable to business reviewers. Semantic validation: `UniqueChildNames` (unique child names) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. `InformationItemHasBusinessName` (information item has business name) in `mde/validation/cim/rules/domain-data.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: `InformationItemExample`.
`required`	`Boolean` [1]	Whether the business considers the information necessary for a valid instance or message. It becomes a required-field decision in contracts and persistence mappings. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/contracts.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/values.eol`.	Either `true` or `false`. Example: `true`.
`collection`	`Boolean` [1]	Whether one occurrence or a set of occurrences is expected. This changes the shape of generated schema fields and the way transformations construct nested data. Semantic validation: `PersonalOrSensitiveInformationHasPrivacyConstraint` (personal or sensitive information has privacy constraint) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. `CollectionInformationHasMultiplicity` (collection information has multiplicity) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/iam.eol`.	Either `true` or `false`. Example: `false`.
`example`	`String` [1]	A representative business value used to clarify format and meaning; it is illustrative data, not a default or a secret. 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/paths.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Information Item Example`.
`allowedValues`	`String` [*]	The finite vocabulary accepted for the item when free text would permit invalid domain states. CIM-to-PIM can use it to construct enum-like contract fields. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/templates/infrastructure/sam-template.egl`.	A collection of values. Example: [`READY`, `READY-2`].
`formatHint`	`String` [1]	A format qualification such as ISO date, currency scale, or identifier convention that primitive type alone cannot express.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Information Item Format Hint`.
`minValue`	`String` [1]	The lower business boundary for numeric, temporal, or ordered values; it turns a narrative rule into a checkable constraint.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `READY`.
`maxValue`	`String` [1]	The upper business boundary, used alongside minValue to prevent values that are technically well-typed but invalid for the domain.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `READY`.
`minLength`	`Integer` [1]	The shortest permitted textual or collection representation, useful for identifiers, descriptions, and bounded payloads. Semantic validation: `LengthBoundsAreConsistent` (length bounds are consistent) in `mde/validation/cim/rules/domain-data.evl` the related value or object must be explicitly provided.	A numeric `Integer` value; use the unit or boundary documented for this attribute. Example: `1`.
`maxLength`	`Integer` [1]	The largest permitted textual or collection representation, protecting contracts and storage from unbounded business input. Semantic validation: `LengthBoundsAreConsistent` (length bounds are consistent) in `mde/validation/cim/rules/domain-data.evl` the related value or object must be explicitly provided.	A numeric `Integer` value; use the unit or boundary documented for this attribute. Example: `1`.
`pattern`	`String` [1]	A regular-expression shape for values such as codes, identifiers, or normalized strings. It captures syntax while businessValidationRule carries richer semantics. 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/validation.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `^[A-Z]{2}-[0-9]{6}$`.
`unit`	`String` [1]	The unit attached to a numeric quantity, such as EUR, seconds, kilograms, or percent, so downstream calculations do not treat a naked number as self-explanatory.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `milliseconds`.
`businessValidationRule`	`String` [1]	The domain rule that primitive typing and simple bounds cannot express. It is a prompt for semantic validation or a deliberate manual decision during refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `amount must be greater than zero`.
`derived`	`Boolean` [1]	Whether the value is calculated from other information rather than independently entered or stored. The derivation must be explained so persistence and contract generation do not duplicate authority. Semantic validation: `CollectionInformationHasMultiplicity` (collection information has multiplicity) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. `DerivedInformationHasDerivationRule` (derived information has derivation rule) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/templates/lambda/go-handler.egl`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/templates/tests/fixtures-readme.egl`.	Either `true` or `false`. Example: `false`.
`derivationRule`	`String` [1]	How a derived value is calculated and from which facts. It preserves the formula or business reasoning needed to reproduce the value in PIM. Semantic validation: `DerivedInformationHasDerivationRule` (derived information has derivation rule) in `mde/validation/cim/rules/domain-data.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'`.
`sourceOfTruth`	`String` [1]	The system, process, or concept that owns the authoritative value. It prevents multiple generated components from silently becoming competing writers. Semantic validation: `SearchOrReportItemHasSourceOfTruth` (search or report item has source of truth) in `mde/validation/cim/rules/domain-data.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: `Information Item Source Of Truth`.
`externallyShared`	`Boolean` [1]	Whether the data crosses the domain boundary. This flag brings contract, privacy, security, and compatibility concerns into the model before implementation.	Either `true` or `false`. Example: `false`.
`auditRelevant`	`Boolean` [1]	Whether creation, change, or access should be attributable for audit purposes, independent of whether the item is personally identifiable.	Either `true` or `false`. Example: `true`.
`searchRelevant`	`Boolean` [1]	Whether the item participates in user search or lookup behavior, informing access patterns and index candidates later in PIM. Semantic validation: `SearchOrReportItemHasSourceOfTruth` (search or report item has source of truth) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass.	Either `true` or `false`. Example: `false`.
`reportingRelevant`	`Boolean` [1]	Whether the item is needed for reporting or analytical views, which may require retention, projection, or read-model treatment. Semantic validation: `SearchOrReportItemHasSourceOfTruth` (search or report item has source of truth) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass.	Either `true` or `false`. Example: `false`.
`retentionRelevant`	`Boolean` [1]	Whether retention or deletion policy must explicitly account for the item rather than inheriting a generic data-store default.	Either `true` or `false`. Example: `false`.
`type`	`PrimitiveBusinessType` [1]	The business primitive used to classify the item before a provider-independent field type is chosen. It is the first step in transforming domain information into schemas and data models. Semantic validation: `StructuredItemsUseObjectOrList` (structured items use object or list) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. `UniqueChildNames` (unique child names) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. 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`.	Exactly one of: `TEXT`, `NUMBER`, `INTEGER`, `DECIMAL`, `BOOLEAN`, `DATE`, `TIME`, `DATETIME`, `MONEY`, `EMAIL`, `PHONE`, `ADDRESS`, `IDENTIFIER`, `ENUMERATION`, `OBJECT`, `LIST`, `DOCUMENT`, `BINARY`. Example: `TEXT`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`cardinality` → `Multiplicity`	containment, [?]	Contains the multiplicity element(s) that make up this information item; the contained objects belong to this model element.
`subItems` → `InformationItem`	containment, [*]; opposite `parent`	Contains the information item element(s) that make up this information item; the contained objects belong to this model element.
`parent` → `InformationItem`	reference; read-only, [?]; opposite `subItems`	References the information item element(s) used as parent by this information item; the target may be shared elsewhere in the model.
`classification` → `DataClassification`	reference, [?]	References the data classification element(s) used as classification by this information item; the target may be shared elsewhere in the model.
`privacyConstraints` → `PrivacyConstraint`	reference, [*]; opposite `dataItems`	References the privacy constraint element(s) used as privacy constraints by this information item; the target may be shared elsewhere in the model.
`complianceConstraints` → `ComplianceConstraint`	reference, [*]	References the compliance constraint element(s) used as compliance constraints by this information item; the target may be shared elsewhere in the model.

`DataClassification`

Represents data classification 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
`confidentialityLevel`	`String` [1]	The access sensitivity assigned by the organization, distinct from the item's business type. It drives who may view or operate on the information.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `INFO`.
`regulatoryCategory`	`String` [1]	The legal or policy category that makes the data subject to special controls, such as health, financial, or regulated information. Semantic validation: `RegulatedDataHasRegulatoryCategory` (regulated data has regulatory category) in `mde/validation/cim/rules/domain-data.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: `Data Classification Regulatory Category`.
`encryptionExpected`	`Boolean` [1]	Whether confidentiality requires encryption at rest or in transit. PIM and PSM security policies use this intent when selecting storage and key controls. Semantic validation: `SensitiveDataRequiresProtectionExpectation` (sensitive data requires protection expectation) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `DataClassification2DataProtectionPolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataClassification`.	Either `true` or `false`. Example: `false`.
`maskingExpected`	`Boolean` [1]	Whether ordinary displays, logs, or support views must hide part of the value. It protects sensitive data even when access is otherwise authorized. Transformation role: ETL rule `DataClassification2DataProtectionPolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataClassification`.	Either `true` or `false`. Example: `false`.
`minimizationRequired`	`Boolean` [1]	Whether the system should collect or retain only the smallest useful amount of this data, making privacy a modeling constraint rather than a documentation afterthought.	Either `true` or `false`. Example: `true`.
`consentRequired`	`Boolean` [1]	Whether processing depends on explicit data-subject consent, which affects workflow, authorization, and deletion handling.	Either `true` or `false`. Example: `true`.
`auditAccessRequired`	`Boolean` [1]	Whether reads as well as writes must be auditable, important for sensitive records where access itself is regulated. Semantic validation: `SensitiveDataRequiresProtectionExpectation` (sensitive data requires protection expectation) in `mde/validation/cim/rules/domain-data.evl` the flag must be enabled for this rule to pass. Transformation role: ETL rule `DataClassification2DataProtectionPolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataClassification`.	Either `true` or `false`. Example: `true`.
`deletionRightApplies`	`Boolean` [1]	Whether a data-subject deletion right applies. This is a lifecycle obligation that can require a cross-store erasure design. Transformation role: ETL rule `DataClassification2DataProtectionPolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataClassification`.	Either `true` or `false`. Example: `false`.
`classificationRationale`	`String` [1]	The reasoning behind the classification and controls. It lets reviewers challenge an overly broad or weak sensitivity decision with evidence. Semantic validation: `RegulatedDataHasRegulatoryCategory` (regulated data has regulatory category) in `mde/validation/cim/rules/domain-data.evl` the value must be present and non-blank. Transformation role: ETL rule `DataClassification2DataProtectionPolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataClassification`.	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.`.
`kind`	`DataKind` [1]	The business sensitivity category, such as personal, financial, health, or authentication secret, used to select the relevant governance policies. Semantic validation: `DataClassificationHasKind` (data classification has kind) in `mde/validation/cim/rules/domain-data.evl` the related value or object must be explicitly provided. `SensitiveDataRequiresProtectionExpectation` (sensitive data requires protection expectation) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `DataClassification2DataProtectionPolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataClassification`.	Exactly one of: `PUBLIC`, `INTERNAL`, `CONFIDENTIAL`, `PERSONAL`, `SENSITIVE_PERSONAL`, `FINANCIAL`, `HEALTH`, `AUTHENTICATION_SECRET`, `REGULATED`. Example: `PUBLIC`.
`identifiability`	`Identifiability` [1]	How directly the information identifies a person. It separates anonymous, pseudonymous, indirect, and direct identification for privacy analysis. Semantic validation: `SensitiveDataRequiresProtectionExpectation` (sensitive data requires protection expectation) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. `PersonalDataHasIdentifiability` (personal data has identifiability) in `mde/validation/cim/rules/domain-data.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `DataClassification2DataProtectionPolicy` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataClassification`.	Exactly one of: `NON_PERSONAL`, `PSEUDONYMOUS`, `DIRECTLY_IDENTIFYING`, `INDIRECTLY_IDENTIFYING`, `ANONYMOUS`. Example: `NON_PERSONAL`.

Relationships

This class declares no direct relationships.