Services, deployment units, and platform mapping

Deployment concepts divide the provider-independent architecture into services, units, environments, and explicit platform-mapping decisions.

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

`ServerlessService`

Represents serverless service in the PIM vocabulary. It specializes TraceableElement, PolicyTarget, ConfigurableElement with the details needed for this modeling concern.

Direct supertypes: TraceableElement, PolicyTarget, 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
`responsibility`	`String` [1]	The capability slice this service owns. It is the PIM counterpart to the CIM capability and is used to keep generated functions and APIs cohesive. Semantic validation: `ServiceResponsibilityRequired` (service responsibility required) in `mde/validation/pim/rules/deployment.evl` the value must be present and non-blank. Transformation role: ETL rule `ServerlessService2StructuredMetadata` in `mde/transformations/pim-to-awspsm/root-stage-stack.etl` reads or derives this feature while refining `ServerlessService`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Reserve inventory for a confirmed order.`.
`ownerTeam`	`String` [1]	Records accountable person, team, or identity for owner team for serverless service. It keeps accountability and access review explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `ServiceOwnerTeamRecommended` (service owner team recommended) in `mde/validation/pim/rules/deployment.evl` the value must be present and non-blank. Transformation role: ETL rule `ServerlessService2StructuredMetadata` in `mde/transformations/pim-to-awspsm/root-stage-stack.etl` reads or derives this feature while refining `ServerlessService`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `orders-team`.
`businessCapabilityRef`	`String` [1]	Stores the business capability ref value on the serverless service. 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 `ServerlessService2StructuredMetadata` in `mde/transformations/pim-to-awspsm/root-stage-stack.etl` reads or derives this feature while refining `ServerlessService`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Serverless Service Business Capability Ref`.
`externallyExposed`	`Boolean` [1]	Records whether externally exposed applies to serverless service. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `ExternallyExposedServiceNeedsApi` (externally exposed service needs api) in `mde/validation/pim/rules/deployment.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`ownsData`	`Boolean` [1]	For a serverless service, the model records whether owns data applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `DataOwningServiceNeedsStore` (data owning service needs store) in `mde/validation/pim/rules/deployment.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`boundaryType`	`BoundaryType` [1]	Records boundary within which boundary type is interpreted for serverless service. It keeps isolation and ownership decisions explicit during review and transformation, so later steps do not have to infer it. Transformation role: ETL rule `ServerlessService2StructuredMetadata` in `mde/transformations/pim-to-awspsm/root-stage-stack.etl` assigns or materializes this feature while refining `ServerlessService`.	Exactly one of: `CAPABILITY_BASED`, `BOUNDED_CONTEXT_BASED`, `PROCESS_BASED`, `DATA_OWNERSHIP_BASED`, `TEAM_OWNERSHIP_BASED`. Example: `CAPABILITY_BASED`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`functions` → `Function`	containment, [*]; opposite `service`	Contains the function element(s) that make up this serverless service; the contained objects belong to this model element.
`apis` → `Api`	containment, [*]; opposite `service`	Contains the api element(s) that make up this serverless service; the contained objects belong to this model element.
`channels` → `EventChannel`	containment, [*]; opposite `service`	Contains the event channel element(s) that make up this serverless service; the contained objects belong to this model element.
`schedules` → `Schedule`	containment, [*]; opposite `service`	Contains the schedule element(s) that make up this serverless service; the contained objects belong to this model element.
`stores` → `StorageElement`	containment, [*]; opposite `service`	Contains the storage element element(s) that make up this serverless service; the contained objects belong to this model element.
`workflows` → `Workflow`	containment, [*]; opposite `service`	Contains the workflow element(s) that make up this serverless service; the contained objects belong to this model element.
`adapters` → `ExternalAdapter`	containment, [*]; opposite `service`	Contains the external adapter element(s) that make up this serverless service; the contained objects belong to this model element.
`constrainedBy` → `ArchitecturePolicy`	reference, [*]	References the architecture policy element(s) used as constrained by by this serverless service; the target may be shared elsewhere in the model.

`ServiceElementMembership`

Represents service element membership 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
`ownershipKind`	`OwnershipKind` [1]	For a service element membership, the model records the accountable person, team, or identity for ownership kind. 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: `OWNS`, `USES_SHARED`, `DEPENDS_ON`, `EXPOSES`. Example: `OWNS`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`service` → `ServerlessService`	reference, [1]	References the serverless service element(s) used as service by this service element membership; the target may be shared elsewhere in the model.
`element` → `DeployableElement`	reference, [1]	References the deployable element element(s) used as element by this service element membership; the target may be shared elsewhere in the model.

`DeploymentUnit`

Represents deployment unit in the PIM vocabulary. It specializes TraceableElement, PolicyTarget, ConfigurableElement with the details needed for this modeling concern.

Direct supertypes: TraceableElement, PolicyTarget, 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
`lifecycle`	`String` [1]	Records the lifecycle value for deployment unit. 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: `Deployment Unit Lifecycle`.
`independentlyDeployable`	`Boolean` [1]	Records whether independently deployable applies to deployment unit. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `IndependentlyDeployableUnitNeedsReleaseStrategy` (independently deployable unit needs release strategy) in `mde/validation/pim/rules/deployment.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `DeploymentUnit2SamStack` in `mde/transformations/pim-to-awspsm/root-stage-stack.etl` assigns or materializes this feature while refining `DeploymentUnit`.	Either `true` or `false`. Example: `false`.
`releaseStrategy`	`String` [1]	Records controlled classification or strategy represented by release strategy for deployment unit. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `IndependentlyDeployableUnitNeedsReleaseStrategy` (independently deployable unit needs release strategy) in `mde/validation/pim/rules/deployment.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: `Deployment Unit Release Strategy`.
`versioningStrategy`	`String` [1]	For a deployment unit, the model records the compatibility/version marker for versioning strategy. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `IndependentlyDeployableUnitNeedsReleaseStrategy` (independently deployable unit needs release strategy) in `mde/validation/pim/rules/deployment.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: `1.0`.
`unitType`	`DeploymentUnitType` [1]	Whether the unit is an application, service, shared infrastructure, library, edge interface, or observability package. It determines the kind of deployment artifact expected.	Exactly one of: `APPLICATION`, `SERVICE`, `SHARED_INFRASTRUCTURE`, `LIBRARY`, `EDGE_INTERFACE`, `OBSERVABILITY`. Example: `APPLICATION`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`services` → `ServerlessService`	reference, [*]	References the serverless service element(s) used as services by this deployment unit; the target may be shared elsewhere in the model.
`contains` → `DeployableElement`	reference, [*]	References the deployable element element(s) used as contains by this deployment unit; the target may be shared elsewhere in the model.
`targetEnvironments` → `Environment`	reference, [*]	References the environment element(s) used as target environments by this deployment unit; the target may be shared elsewhere in the model.

`Environment`

Represents environment in the PIM vocabulary. It specializes TraceableElement, EnvironmentTarget, PolicyTarget with the details needed for this modeling concern.

Direct supertypes: TraceableElement, EnvironmentTarget, 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
`nameSuffix`	`String` [1]	Records the name suffix value for the environment. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `Environment2AwsStage` in `mde/transformations/pim-to-awspsm/root-stage-stack.etl` assigns or materializes this feature while refining `Environment`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Environment Name Suffix`.
`productionLike`	`Boolean` [1]	Whether non-production is expected to behave like production for security, scale, or operational testing. It prevents a test environment from accidentally receiving weak controls. Semantic validation: `ProdEnvironmentIsProductionLike` (prod environment is production like) in `mde/validation/pim/rules/deployment.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Environment2AwsStage` in `mde/transformations/pim-to-awspsm/root-stage-stack.etl` assigns or materializes this feature while refining `Environment`.	Either `true` or `false`. Example: `true`.
`requiresApproval`	`Boolean` [1]	Records whether requires approval applies to environment. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `ProdEnvironmentShouldRequireApproval` (prod environment should require approval) in `mde/validation/pim/rules/deployment.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Environment2AwsStage` in `mde/transformations/pim-to-awspsm/root-stage-stack.etl` assigns or materializes this feature while refining `Environment`.	Either `true` or `false`. Example: `false`.
`environmentClass`	`EnvironmentClass` [1]	The lifecycle stage represented by the environment. Transformations use it to create AWS stages and to apply stronger safeguards to production. Semantic validation: `ProdEnvironmentIsProductionLike` (prod environment is production like) in `mde/validation/pim/rules/deployment.evl` the feature participates in a semantic validation condition. `ProdEnvironmentShouldRequireApproval` (prod environment should require approval) in `mde/validation/pim/rules/deployment.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `Environment2AwsStage` in `mde/transformations/pim-to-awspsm/root-stage-stack.etl` assigns or materializes this feature while refining `Environment`. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/paths.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/validation.eol`.	Exactly one of: `LOCAL`, `DEV`, `TEST`, `STAGING`, `PROD`, `SANDBOX`. Example: `LOCAL`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`configurationSets` → `ConfigurationSet`	reference, [*]	References the configuration set element(s) used as configuration sets by this environment; the target may be shared elsewhere in the model.
`parameters` → `ConfigParameter`	reference, [*]	References the config parameter element(s) used as parameters by this environment; the target may be shared elsewhere in the model.
`variables` → `EnvironmentVariable`	reference, [*]	References the environment variable element(s) used as variables by this environment; the target may be shared elsewhere in the model.

`ImplementationProfile`

Represents implementation profile 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
`languageVersion`	`String` [1]	Records compatibility/version marker for language version for implementation profile. It keeps compatibility and contract evolution 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: `1.0`.
`sourceLayout`	`String` [1]	Stores the origin/source selected for source layout on the implementation profile. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `ProfileHasGenerationBasics` (profile has generation basics) in `mde/validation/pim/rules/deployment.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: `Implementation Profile Source Layout`.
`testFramework`	`String` [1]	Records the test framework value for implementation profile. 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: `Implementation Profile Test Framework`.
`lintCommand`	`String` [1]	Records the lint command value for implementation profile. 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: `Implementation Profile Lint Command`.
`formatCommand`	`String` [1]	Records the serialization/content format for format command for the implementation profile. This keeps the decision explicit even when the element's class or relationships remain unchanged. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Implementation Profile Format Command`.
`buildCommand`	`String` [1]	Stores the build command value on the implementation profile. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `ProfileHasGenerationBasics` (profile has generation basics) in `mde/validation/pim/rules/deployment.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: `Implementation Profile Build Command`.
`dependencyPolicy`	`String` [1]	Stores the dependency policy value on the implementation profile. 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: `STANDARD`.
`generateTypedContracts`	`Boolean` [1]	Records whether generate typed contracts applies to implementation profile. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `RuntimeValidationShouldGenerateTypedContracts` (runtime validation should generate typed contracts) in `mde/validation/pim/rules/deployment.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`generateRuntimeValidation`	`Boolean` [1]	Records whether generate runtime validation applies to implementation profile. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `RuntimeValidationShouldGenerateTypedContracts` (runtime validation should generate typed contracts) in `mde/validation/pim/rules/deployment.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`primaryLanguage`	`RuntimeLanguage` [1]	Records the controlled classification or strategy for primary language in the implementation profile. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `PackageManagerMatchesRuntimeLanguage` (package manager matches runtime language) in `mde/validation/pim/rules/deployment.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/lib/cfn.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/paths.eol`.	Exactly one of: `TYPESCRIPT`, `JAVASCRIPT`, `PYTHON`, `JAVA`, `CSHARP`, `GO`, `RUST`, `CUSTOM`. Example: `TYPESCRIPT`.
`packageManager`	`PackageManager` [1]	Stores the controlled classification or strategy represented by package manager on the implementation profile. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `PackageManagerMatchesRuntimeLanguage` (package manager matches runtime language) in `mde/validation/pim/rules/deployment.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/lib/trace.eol`.	Exactly one of: `NPM`, `PNPM`, `YARN`, `PIP`, `POETRY`, `MAVEN`, `GRADLE`, `DOTNET`, `GO_MOD`, `CARGO`, `NONE`. Example: `NPM`.

Relationships

This class declares no direct relationships.

`PlatformCapability`

Represents platform capability 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
`platform`	`String` [1]	For a platform capability, the model records the platform 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: `Platform Capability Platform`.
`providerService`	`String` [1]	Records the provider service value for the platform capability. 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: `Platform Capability Provider Service`.
`limitations`	`String` [1]	For a platform capability, the model records the limitations 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: `Platform Capability Limitations`.
`supportLevel`	`SupportLevel` [1]	For a platform capability, the model records the controlled classification or strategy represented by support level. 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: `SUPPORTED_FIRST_CLASS`, `SUPPORTED_WITH_ASSUMPTIONS`, `REQUIRES_MANUAL_DECISION`, `METADATA_ONLY`, `UNSUPPORTED`. Example: `SUPPORTED_FIRST_CLASS`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`supportedPimConcepts` → `ModelElement`	reference, [*]	References the model element element(s) used as supported pim concepts by this platform capability; the target may be shared elsewhere in the model.

`PlatformMappingAssessment`

Represents platform mapping assessment 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
`rationale`	`String` [1]	The reasoning that lets a reviewer understand why this modeling choice was made. Here it is attached to the platform mapping assessment, so the shared meaning travels with this particular model element. 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/validation.eol`.	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.`.
`suggestedProviderService`	`String` [1]	Stores the suggested provider service value on the platform mapping assessment. 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: `Platform Mapping Assessment Suggested Provider Service`.
`supportLevel`	`SupportLevel` [1]	For a platform mapping assessment, the model records the controlled classification or strategy represented by support level. 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: `SUPPORTED_FIRST_CLASS`, `SUPPORTED_WITH_ASSUMPTIONS`, `REQUIRES_MANUAL_DECISION`, `METADATA_ONLY`, `UNSUPPORTED`. Example: `SUPPORTED_FIRST_CLASS`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`source` → `ModelElement`	reference, [1]	References the model element element(s) used as source by this platform mapping assessment; the target may be shared elsewhere in the model.