Stores, data models, and access patterns

Data concepts capture storage intent, data shapes, change streams, indexes, access patterns, and the link between reads/writes and compute.

Source: mde/metamodels/pim/pim-data.emf.

`StorageElement`

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

Direct supertypes: TraceableElement, DeployableElement, FlowEndpoint, PolicyTarget, ProtectedResource, DataAccessTarget, ConfigurableElement. 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
`persistent`	`Boolean` [1]	For a storage element, the model records whether persistent applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `SensitiveStorageMustBeEncrypted` (sensitive storage must be encrypted) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition. `PersistentStorageShouldHaveRetentionPolicy` (persistent storage should have retention policy) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`encrypted`	`Boolean` [1]	Records whether encrypted applies to storage element. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `SensitiveStorageMustBeEncrypted` (sensitive storage must be encrypted) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`containsPersonalData`	`Boolean` [1]	For a storage element, the model records the data-sensitivity classification for contains personal data. 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`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`service` → `ServerlessService`	reference; read-only, [1]; opposite `stores`	References the serverless service element(s) used as service by this storage element; the target may be shared elsewhere in the model.
`retentionPolicy` → `RetentionPolicy`	reference, [?]	References the retention policy element(s) used as retention policy by this storage element; the target may be shared elsewhere in the model.
`backupPolicy` → `BackupPolicy`	reference, [?]	References the backup policy element(s) used as backup policy by this storage element; the target may be shared elsewhere in the model.
`dataProtectionPolicies` → `DataProtectionPolicy`	reference, [*]	References the data protection policy element(s) used as data protection policies by this storage element; the target may be shared elsewhere in the model.

`DataStore`

Represents data store in the PIM vocabulary. It specializes StorageElement, RoutingTarget, SubscriptionTarget with the details needed for this modeling concern.

Direct supertypes: StorageElement, RoutingTarget, SubscriptionTarget. 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
`transactional`	`Boolean` [1]	Records whether transactional applies to data store. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `DataStoreHasAccessPattern` (data store has access pattern) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition. `TransactionalStoreNeedsTransactionalConsistency` (transactional store needs transactional consistency) in `mde/validation/pim/rules/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 `DataStore`.	Either `true` or `false`. Example: `false`.
`readOptimized`	`Boolean` [1]	For a data store, the model records whether read optimized applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataStore`.	Either `true` or `false`. Example: `false`.
`writeOptimized`	`Boolean` [1]	Records whether write optimized applies to data store. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataStore`.	Either `true` or `false`. Example: `false`.
`appendOnly`	`Boolean` [1]	Records whether append only applies to data store. 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 `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataStore`.	Either `true` or `false`. Example: `false`.
`changeStreamRequired`	`Boolean` [1]	Records whether change stream required applies to data store. The field records an explicit architectural or governance decision as an explicit, reviewable input. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataStore`. ETL rule `DataStore2DynamoDbTable` in `mde/transformations/pim-to-awspsm/data-messaging-events.etl` reads or derives this feature while refining `DataStore`.	Either `true` or `false`. Example: `true`.
`pointInTimeRecoveryRequired`	`Boolean` [1]	Records whether point in time recovery required applies to data store. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `SourceOfTruthShouldHavePitrOrBackup` (source of truth should have pitr or backup) in `mde/validation/pim/rules/data.evl` the related value or object must be explicitly provided. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataStore`. ETL rule `DataStore2DynamoDbTable` in `mde/transformations/pim-to-awspsm/data-messaging-events.etl` assigns or materializes this feature while refining `DataStore`.	Either `true` or `false`. Example: `true`.
`expectedDataVolume`	`String` [1]	Records the expected data volume value for the data store. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataStore`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Data Store Expected Data Volume`.
`expectedAccessRate`	`String` [1]	Records the expected access rate value for the data store. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataStore`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Data Store Expected Access Rate`.
`storeKind`	`StoreKind` [1]	Stores the controlled classification or strategy represented by store kind on the data store. 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 `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataStore`. ETL rule `DataStore2DynamoDbTable` in `mde/transformations/pim-to-awspsm/data-messaging-events.etl` assigns or materializes this feature while refining `DataStore`.	Exactly one of: `KEY_VALUE`, `DOCUMENT`, `RELATIONAL`, `GRAPH`, `SEARCH`, `TIME_SERIES`, `CACHE`, `OBJECT`. Example: `KEY_VALUE`.
`consistencyNeed`	`ConsistencyNeed` [1]	Records controlled classification or strategy represented by consistency need for data store. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `TransactionalStoreNeedsTransactionalConsistency` (transactional store needs transactional consistency) in `mde/validation/pim/rules/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 `DataStore`.	Exactly one of: `EVENTUAL`, `STRONG`, `TRANSACTIONAL`, `READ_YOUR_WRITES`. Example: `EVENTUAL`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`ownedDataModels` → `DataModel`	containment, [*]; opposite `dataStore`	Contains the data model element(s) that make up this data store; the contained objects belong to this model element.
`accessPatterns` → `AccessPattern`	containment, [*]; opposite `dataStore`	Contains the access pattern element(s) that make up this data store; the contained objects belong to this model element.
`indexCandidates` → `IndexCandidate`	containment, [*]; opposite `dataStore`	Contains the index candidate element(s) that make up this data store; the contained objects belong to this model element.
`changeStream` → `DataChangeStream`	containment, [?]; opposite `dataStore`	Contains the data change stream element(s) that make up this data store; the contained objects belong to this model element.

`DataChangeStream`

Represents data change stream in the PIM vocabulary. It specializes TraceableElement, DeployableElement, InvocationSource, EventCarrier, FlowEndpoint, PolicyTarget with the details needed for this modeling concern.

Direct supertypes: TraceableElement, DeployableElement, InvocationSource, EventCarrier, FlowEndpoint, PolicyTarget. 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
`enabled`	`Boolean` [1]	Records whether enabled applies to data change stream. 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`.
`orderingRequirement`	`OrderingRequirement` [1]	Records the precedence value for ordering requirement for the data change stream. 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: `NONE`, `PER_KEY`, `GLOBAL`. Example: `NONE`.
`deliverySemantics`	`DeliverySemantics` [1]	Records the controlled classification or strategy for delivery semantics in the data change stream. 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: `AT_MOST_ONCE`, `AT_LEAST_ONCE`, `EFFECTIVELY_ONCE_WITH_IDEMPOTENCY`, `EXACTLY_ONCE_REQUIRED`. Example: `AT_MOST_ONCE`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`dataStore` → `DataStore`	reference; read-only, [1]; opposite `changeStream`	References the data store element(s) used as data store by this data change stream; the target may be shared elsewhere in the model.
`emittedEvents` → `EventType`	reference, [*]	References the event type element(s) used as emitted events by this data change stream; the target may be shared elsewhere in the model.

`ObjectStore`

Represents object store in the PIM vocabulary. It specializes StorageElement, InvocationSource, RoutingTarget, SubscriptionTarget, EventCarrier with the details needed for this modeling concern.

Direct supertypes: StorageElement, InvocationSource, RoutingTarget, SubscriptionTarget, EventCarrier. 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
`objectTypes`	`String` [*]	For a object store, the model records the object types 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 collection of values. Example: [`BUSINESS`, `BUSINESS-2`].
`versioningRequired`	`Boolean` [1]	Records compatibility/version marker for versioning required for object store. It keeps compatibility and contract evolution explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `VersionedObjectStoreShouldHaveLifecycleDecision` (versioned object store should have lifecycle decision) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `ObjectStore2S3Bucket` in `mde/transformations/pim-to-awspsm/data-messaging-events.etl` reads or derives this feature while refining `ObjectStore`.	Either `true` or `false`. Example: `true`.
`lifecyclePolicyRequired`	`Boolean` [1]	Records whether lifecycle policy required applies to object store. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `VersionedObjectStoreShouldHaveLifecycleDecision` (versioned object store should have lifecycle decision) in `mde/validation/pim/rules/data.evl` the value must be present and non-blank. Transformation role: ETL rule `ObjectStore2S3Bucket` in `mde/transformations/pim-to-awspsm/data-messaging-events.etl` reads or derives this feature while refining `ObjectStore`.	Either `true` or `false`. Example: `true`.
`eventNotificationRequired`	`Boolean` [1]	Records whether event notification required applies to object store. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `ObjectStoreWithEventsShouldDeclareEventTypes` (object store with events should declare event types) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `ObjectStore2S3Bucket` in `mde/transformations/pim-to-awspsm/data-messaging-events.etl` assigns or materializes this feature while refining `ObjectStore`. ETL rule `ObjectStore2S3Bucket` in `mde/transformations/pim-to-awspsm/data-messaging-events.etl` reads or derives this feature while refining `ObjectStore`.	Either `true` or `false`. Example: `true`.
`maxObjectSize`	`String` [1]	For a object store, the model records the max object size 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: `Object Store Max Object Size`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`notificationRules` → `ObjectNotificationRule`	containment, [*]; opposite `objectStore`	Contains the object notification rule element(s) that make up this object store; the contained objects belong to this model element.
`objectMetadataSchemas` → `Schema`	reference, [*]	References the schema element(s) used as object metadata schemas by this object store; the target may be shared elsewhere in the model.
`emittedEvents` → `EventType`	reference, [*]	References the event type element(s) used as emitted events by this object store; the target may be shared elsewhere in the model.

`ObjectNotificationRule`

Represents object notification rule in the PIM 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
`eventTypes`	`String` [*]	Records the event types value for object notification rule. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`.	A collection of values. Example: [`BUSINESS`, `BUSINESS-2`].
`filterPrefix`	`String` [1]	Stores the filter prefix value on the object notification rule. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Generation role: 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: `Object Notification Rule Filter Prefix`.
`filterSuffix`	`String` [1]	Records the filter suffix value for object notification rule. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Generation role: 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: `Object Notification Rule Filter Suffix`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`objectStore` → `ObjectStore`	reference; read-only, [1]; opposite `notificationRules`	References the object store element(s) used as object store by this object notification rule; the target may be shared elsewhere in the model.
`emittedEvents` → `EventType`	reference, [*]	References the event type element(s) used as emitted events by this object notification rule; the target may be shared elsewhere in the model.
`targets` → `RoutingTarget`	reference, [*]	References the routing target element(s) used as targets by this object notification rule; the target may be shared elsewhere in the model.

`DataModel`

Represents data model in the PIM vocabulary. It specializes TraceableElement, FlowEndpoint, PolicyTarget with the details needed for this modeling concern.

Direct supertypes: TraceableElement, FlowEndpoint, PolicyTarget. 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
`aggregateRef`	`String` [1]	Records the aggregate ref value for the data model. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataModel`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Data Model Aggregate Ref`.
`ownershipBoundary`	`String` [1]	Stores the accountable person, team, or identity for ownership boundary on the data model. The field records accountability and access review as an explicit, reviewable input. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataModel`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `orders-team`.
`sourceOfTruth`	`Boolean` [1]	For a data model, the model records the origin/source selected for source of truth. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `SourceOfTruthCannotBeReadModel` (source of truth cannot be read model) in `mde/validation/pim/rules/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 `DataModel`.	Either `true` or `false`. Example: `false`.
`readModel`	`Boolean` [1]	For a data model, the model records whether read model applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `SourceOfTruthCannotBeReadModel` (source of truth cannot be read model) in `mde/validation/pim/rules/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 `DataModel`.	Either `true` or `false`. Example: `false`.
`auditRequired`	`Boolean` [1]	Records whether audit required applies to data model. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataModel`.	Either `true` or `false`. Example: `true`.
`dataModelKind`	`SchemaKind` [1]	For a data model, the model records the controlled classification or strategy represented by data model kind. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Transformation role: ETL rule `Aggregate2DataStore` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `DataModel`.	Exactly one of: `REQUEST`, `RESPONSE`, `ERROR`, `EVENT`, `MESSAGE`, `ENTITY`, `VALUE_OBJECT`, `READ_MODEL`, `CONFIGURATION`. Example: `REQUEST`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`storageFields` → `DataField`	containment, [*]; opposite `dataModel`	Contains the data field element(s) that make up this data model; the contained objects belong to this model element.
`dataStore` → `DataStore`	reference; read-only, [1]; opposite `ownedDataModels`	References the data store element(s) used as data store by this data model; the target may be shared elsewhere in the model.
`schema` → `Schema`	reference, [1]	References the schema element(s) used as schema by this data model; the target may be shared elsewhere in the model.
`accessPatterns` → `AccessPattern`	reference, [*]	References the access pattern element(s) used as access patterns by this data model; the target may be shared elsewhere in the model.

`DataField`

Represents data field in the PIM 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
`identifier`	`Boolean` [1]	Records whether identifier applies to data field. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `SensitiveDataFieldIsClassified` (sensitive data field is classified) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition. `IdentifierFieldShouldBeRequired` (identifier field should be required) in `mde/validation/pim/rules/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`.	Either `true` or `false`. Example: `false`.
`partitionKeyCandidate`	`Boolean` [1]	Records whether partition key candidate applies to data field. 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`.
`sortKeyCandidate`	`Boolean` [1]	For a data field, the model records whether sort key candidate 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`.
`indexedCandidate`	`Boolean` [1]	For a data field, the model records whether indexed candidate 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`.
`required`	`Boolean` [1]	Records whether required applies to data field. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `SensitiveDataFieldIsClassified` (sensitive data field is classified) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition. `IdentifierFieldShouldBeRequired` (identifier field should be required) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `true`.
`personalData`	`Boolean` [1]	For a data field, the model records the data-sensitivity classification for personal data. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `SensitiveDataFieldIsClassified` (sensitive data field is classified) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`sensitiveData`	`Boolean` [1]	Stores the data-sensitivity classification for sensitive data on the data field. The field records privacy, encryption, and access decisions as an explicit, reviewable input. Semantic validation: `SensitiveDataFieldIsClassified` (sensitive data field is classified) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`classification`	`String` [1]	Stores the data-sensitivity classification for classification on the data field. The field records privacy, encryption, and access decisions as an explicit, reviewable input. Semantic validation: `SensitiveDataFieldIsClassified` (sensitive data field is classified) in `mde/validation/pim/rules/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`.
`storageName`	`String` [1]	For a data field, the model records the stable name/key/code used for storage name. 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: `DataFieldExample`.
`fieldType`	`FieldType` [1]	For a data field, the model records the controlled classification or strategy represented by field 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: `STRING`, `INTEGER`, `NUMBER`, `BOOLEAN`, `DATE`, `TIME`, `DATETIME`, `OBJECT`, `ARRAY`, `ENUM`, `BINARY`, `MONEY`, `UUID`, `EMAIL`, `URI`, `MAP`, `UNION`. Example: `STRING`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`dataModel` → `DataModel`	reference; read-only, [1]; opposite `storageFields`	References the data model element(s) used as data model by this data field; the target may be shared elsewhere in the model.

`AccessPattern`

Represents access pattern in the PIM 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
`patternName`	`String` [1]	Records the validation pattern for pattern name for the access pattern. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `^[A-Z][A-Za-z0-9_-]*$`.
`queryBy`	`String` [1]	Records the query by value for access pattern. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `AccessPatternNamesQueryShape` (access pattern names query shape) in `mde/validation/pim/rules/data.evl` the rule's diagnostic or remediation guidance refers to this feature. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Access Pattern Query By`.
`sortBy`	`String` [1]	Records the sort by value for the access pattern. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `AccessPatternNamesQueryShape` (access pattern names query shape) in `mde/validation/pim/rules/data.evl` the rule's diagnostic or remediation guidance refers to this feature. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`. 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: `Access Pattern Sort By`.
`filterBy`	`String` [1]	Records the filter by value for access pattern. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `AccessPatternNamesQueryShape` (access pattern names query shape) in `mde/validation/pim/rules/data.evl` the rule's diagnostic or remediation guidance refers to this feature. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Access Pattern Filter By`.
`projection`	`String` [1]	Records the projection value for access pattern. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `AccessPatternNamesQueryShape` (access pattern names query shape) in `mde/validation/pim/rules/data.evl` the rule's diagnostic or remediation guidance refers to this feature. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`. Generation role: 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: `Access Pattern Projection`.
`highCardinality`	`Boolean` [1]	For a access pattern, the model records whether high cardinality applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `HighFrequencyAccessPatternShouldHaveIndex` (high frequency access pattern should have index) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`. ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` reads or derives this feature while refining `AccessPattern`.	Either `true` or `false`. Example: `false`.
`highFrequency`	`Boolean` [1]	Records whether high frequency applies to access pattern. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `HighFrequencyAccessPatternShouldHaveIndex` (high frequency access pattern should have index) in `mde/validation/pim/rules/data.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`.	Either `true` or `false`. Example: `false`.
`stronglyConsistentReadRequired`	`Boolean` [1]	Records whether strongly consistent read required applies to access pattern. 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 `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`.	Either `true` or `false`. Example: `true`.
`transactionalWriteRequired`	`Boolean` [1]	Records whether transactional write required applies to access pattern. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`.	Either `true` or `false`. Example: `true`.
`expectedItemsReturned`	`Integer` [1]	Records the expected items returned value for access pattern. It keeps an operational boundary that should not be left to provider defaults explicit during review and transformation, so later steps do not have to infer it. Transformation role: ETL rule `Query2AccessPattern` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `AccessPattern`.	A numeric `Integer` value; use the unit or boundary documented for this attribute. Example: `1`.
`latencyTargetMs`	`String` [1]	Records the destination selected for latency target ms for the access pattern. 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: `Access Pattern Latency Target Ms`.
`operation`	`DataAccessMode` [1]	Records controlled classification or strategy represented by operation for access pattern. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `AccessPatternOperationDefined` (access pattern operation defined) in `mde/validation/pim/rules/data.evl` the related value or object must be explicitly provided. `AccessPatternNamesQueryShape` (access pattern names query shape) in `mde/validation/pim/rules/data.evl` the rule's diagnostic or remediation guidance refers to this feature. 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`.	Exactly one of: `READ`, `WRITE`, `READ_WRITE`, `APPEND`, `DELETE`. Example: `READ`.
`accessPatternKind`	`AccessPatternKind` [1]	Stores the validation pattern for access pattern kind on the access pattern. The field records input/schema validation 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.	Exactly one of: `GET_BY_ID`, `QUERY_BY_KEY`, `SCAN_FILTERED`, `SEARCH_TEXT`, `AGGREGATE_REPORT`, `WRITE_COMMAND`, `APPEND_EVENT`. Example: `GET_BY_ID`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`dataStore` → `DataStore`	reference; read-only, [1]; opposite `accessPatterns`	References the data store element(s) used as data store by this access pattern; the target may be shared elsewhere in the model.
`usedByFunctions` → `FunctionTarget`	reference, [*]	References the function target element(s) used as used by functions by this access pattern; the target may be shared elsewhere in the model.
`exposedByRoutes` → `RouteEndpoint`	reference, [*]	References the route endpoint element(s) used as exposed by routes by this access pattern; the target may be shared elsewhere in the model.

`IndexCandidate`

Represents index candidate in the PIM 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
`indexPurpose`	`String` [1]	Records the human explanation of index purpose for the index candidate. 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: `Reserve inventory for a confirmed order.`.
`partitionKeyField`	`String` [1]	For a index candidate, the model records the data location or endpoint represented by partition key field. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `ProductionIndexSupportsAccessPattern` (production index supports access pattern) in `mde/validation/pim/rules/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`.
`sortKeyField`	`String` [1]	Stores the data location or endpoint represented by sort key field on the index candidate. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. 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: `orderId`.
`projectionFields`	`String` [*]	Records the projection fields value for index candidate. 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 collection of values. Example: [`Index Candidate Projection Fields`, `Index Candidate Projection Fields-2`].
`unique`	`Boolean` [1]	For a index candidate, the model records whether unique applies. 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/sam.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/validation.eol`.	Either `true` or `false`. Example: `false`.
`requiredForProduction`	`Boolean` [1]	For a index candidate, the model records whether required for production applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `ProductionIndexSupportsAccessPattern` (production index supports access pattern) in `mde/validation/pim/rules/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/trace.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/templates/docs/generation-report.egl`.	Either `true` or `false`. Example: `true`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`dataStore` → `DataStore`	reference; read-only, [1]; opposite `indexCandidates`	References the data store element(s) used as data store by this index candidate; the target may be shared elsewhere in the model.
`supportsAccessPatterns` → `AccessPattern`	reference, [*]	References the access pattern element(s) used as supports access patterns by this index candidate; the target may be shared elsewhere in the model.

`DataAccess`

Represents data access in the PIM 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
`transactional`	`Boolean` [1]	Records whether transactional applies to data access. 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`.
`purpose`	`String` [1]	Stores the human explanation of purpose on the data access. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `GeneratesOrReferencesPermission` (generates or references permission) in `mde/validation/pim/rules/data.evl` the value must be present and non-blank. `DataAccessHasPurpose` (data access has purpose) in `mde/validation/pim/rules/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: `Reserve inventory for a confirmed order.`.
`mode`	`DataAccessMode` [1]	Records controlled classification or strategy represented by mode for data access. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `DataAccessConsistentWithFunctionRefs` (data access consistent with function refs) in `mde/validation/pim/rules/data.evl` the value participates in a membership or uniqueness check. 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`.	Exactly one of: `READ`, `WRITE`, `READ_WRITE`, `APPEND`, `DELETE`. Example: `READ`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`function` → `FunctionTarget`	reference, [1]	References the function target element(s) used as function by this data access; the target may be shared elsewhere in the model.
`store` → `StorageElement`	reference, [1]	References the storage element element(s) used as store by this data access; the target may be shared elsewhere in the model.
`dataModels` → `DataModel`	reference, [*]	References the data model element(s) used as data models by this data access; the target may be shared elsewhere in the model.
`accessPatterns` → `AccessPattern`	reference, [*]	References the access pattern element(s) used as access patterns by this data access; the target may be shared elsewhere in the model.