PIM validation: Deployment
Deployment rules check that services, deployment units, environments, and implementation profiles form a realizable architecture. They connect ownership to membership, production intent to approval, and code-generation settings to a coherent language/runtime toolchain.
Source profile: mde/validation/pim/rules/deployment.evl.
Reading these rules
Each entry preserves the actual EVL guard and check. Treat the guard as the applicability boundary. When it evaluates to false, EVL skips the rule. The diagnostic is the message emitted at runtime, and its final sentence usually gives the repository's recommended repair.
ServiceResponsibilityRequired
Context: PIM!ServerlessService
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:8
Why this rule exists
The rule checks whether service responsibility required. The serverless service element provides the relevant evidence through responsibility, display name. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-SVC-001] Service ' ' has no responsibility.
When it applies
No guard is defined, so the check runs for every instance of this context in the validated model.
No guard expression is present. Every instance of the context is checked.
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.responsibility.hasText()
This rule reads: responsibility, displayName.
Diagnostic and repair
[PIM-SVC-001] Service ' ' has no responsibility. Fix: describe the business capability, bounded context, process step or architectural role this service owns.
How to fix it:
describe the business capability, bounded context, process step or architectural role this service owns.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
ServiceOwnsAtLeastOneElement
Context: PIM!ServerlessService
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:14
Why this rule exists
The rule checks whether service owns at least one element. The serverless service element provides the relevant evidence through owned elements, display name. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-SVC-002] Service ' ' does not own any PIM elements.
When it applies
No guard is defined, so the check runs for every instance of this context in the validated model.
No guard expression is present. Every instance of the context is checked.
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.ownedElements().notEmpty()
This rule reads: ownedElements, displayName.
Diagnostic and repair
[PIM-SVC-002] Service ' ' does not own any PIM elements. Fix: attach owned functions, APIs, channels, stores, workflows or adapters, or remove the empty service.
How to fix it:
attach owned functions, APIs, channels, stores, workflows or adapters, or remove the empty service.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
OwnedElementsHaveMembershipRecords
Context: PIM!ServerlessService
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:20
Why this rule exists
The rule checks whether owned elements have membership records. The serverless service element provides the relevant evidence through owned elements, has membership for, display name. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-SVC-002A] Service ' ' has owned elements without ServiceElementMembership records.
When it applies
No guard is defined, so the check runs for every instance of this context in the validated model.
No guard expression is present. Every instance of the context is checked.
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.ownedElements().forAll(elementItem | self.hasMembershipFor(elementItem))
This rule reads: ownedElements, hasMembershipFor, displayName.
Diagnostic and repair
[PIM-SVC-002A] Service ' ' has owned elements without ServiceElementMembership records. Fix: generate one membership for every contained deployable.
How to fix it:
generate one membership for every contained deployable.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
ExternallyExposedServiceNeedsApi
Context: PIM!ServerlessService
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:26
Why this rule exists
The rule checks whether externally exposed service needs api. The serverless service element provides the relevant evidence through externally exposed, apis, display name. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-SVC-003] Externally exposed service ' ' owns no API.
When it applies
The rule is considered only when the guard below is true. A false guard is intentional: it means this invariant is not relevant to the current variant or modeling situation.
guard : self.externallyExposed.isTrue()
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.apis.notEmpty()
This rule reads: externallyExposed, apis, displayName.
Diagnostic and repair
[PIM-SVC-003] Externally exposed service ' ' owns no API. Fix: add an Api/ApiRoute model or mark externallyExposed as false if exposure is indirect.
How to fix it:
add an Api/ApiRoute model or mark externallyExposed as false if exposure is indirect.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
DataOwningServiceNeedsStore
Context: PIM!ServerlessService
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:33
Why this rule exists
The rule checks whether data owning service needs store. The serverless service element provides the relevant evidence through owns data, stores, display name. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-SVC-004] Data-owning service ' ' owns no storage element.
When it applies
The rule is considered only when the guard below is true. A false guard is intentional: it means this invariant is not relevant to the current variant or modeling situation.
guard : self.ownsData.isTrue()
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.stores.notEmpty()
This rule reads: ownsData, stores, displayName.
Diagnostic and repair
[PIM-SVC-004] Data-owning service ' ' owns no storage element. Fix: attach a DataStore or ObjectStore that represents the owned data boundary.
How to fix it:
attach a DataStore or ObjectStore that represents the owned data boundary.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
ServiceOwnerTeamRecommended
Context: PIM!ServerlessService
Classification: Advisory critique (warning)
Source: mde/validation/pim/rules/deployment.evl:40
Why this rule exists
The rule checks whether service owner team recommended. It examines owner team, display name. Within this part of the model, services and deployment units can be assembled into environments with a coherent implementation toolchain. The gap is [PIM-SVC-005] Service ' ' has no ownerTeam. Suggested fix: set the owning team so generated documentation and production readiness reports have an accountable owner. A later transformation, generator, or reviewer would otherwise have to infer the missing decision.
When it applies
No guard is defined, so the check runs for every instance of this context in the validated model.
No guard expression is present. Every instance of the context is checked.
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.ownerTeam.hasText()
This rule reads: ownerTeam, displayName.
Diagnostic and repair
[PIM-SVC-005] Service ' ' has no ownerTeam. Suggested fix: set the owning team so generated documentation and production readiness reports have an accountable owner.
How to fix it:
This is advisory rather than a structural blocker. Decide whether the modeled situation genuinely needs the recommendation; if it does, change the referenced model features so the check evaluates to true and record the rationale when the omission is intentional.
A critique does not necessarily make the model invalid. It is a deliberate quality/readiness signal; disposition it by improving the model, documenting why it is acceptable, or carrying the decision into the review record.
DeploymentUnitContainsElements
Context: PIM!DeploymentUnit
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:50
Why this rule exists
The rule checks whether deployment unit contains elements. The deployment unit element provides the relevant evidence through contains, display name. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-DU-001] Deployment unit ' ' contains no deployable elements.
When it applies
No guard is defined, so the check runs for every instance of this context in the validated model.
No guard expression is present. Every instance of the context is checked.
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.contains.notEmpty()
This rule reads: contains, displayName.
Diagnostic and repair
[PIM-DU-001] Deployment unit ' ' contains no deployable elements. Fix: add the functions, APIs, channels, workflows, adapters, stores, schedules or configuration that should deploy together.
How to fix it:
add the functions, APIs, channels, workflows, adapters, stores, schedules or configuration that should deploy together.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
DeploymentUnitTargetsEnvironment
Context: PIM!DeploymentUnit
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:56
Why this rule exists
The rule checks whether deployment unit targets environment. The deployment unit element provides the relevant evidence through target environments, display name. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-DU-002] Deployment unit ' ' has no target environments.
When it applies
No guard is defined, so the check runs for every instance of this context in the validated model.
No guard expression is present. Every instance of the context is checked.
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.targetEnvironments.notEmpty()
This rule reads: targetEnvironments, displayName.
Diagnostic and repair
[PIM-DU-002] Deployment unit ' ' has no target environments. Fix: reference DEV/TEST/STAGING/PROD or another Environment where the unit can be generated/deployed.
How to fix it:
reference DEV/TEST/STAGING/PROD or another Environment where the unit can be generated/deployed.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
IndependentlyDeployableUnitNeedsReleaseStrategy
Context: PIM!DeploymentUnit
Classification: Advisory critique (warning)
Source: mde/validation/pim/rules/deployment.evl:62
Why this rule exists
The rule checks whether independently deployable unit needs release strategy. It examines independently deployable, release strategy, versioning strategy, display name. Within this part of the model, services and deployment units can be assembled into environments with a coherent implementation toolchain. The gap is [PIM-DU-003] Independently deployable unit ' ' lacks release or versioning strategy. Suggested fix: define how this unit is versioned, promoted and rolled back independently. A later transformation, generator, or reviewer would otherwise have to infer the missing decision.
When it applies
The rule is considered only when the guard below is true. A false guard is intentional: it means this invariant is not relevant to the current variant or modeling situation.
guard : self.independentlyDeployable.isTrue()
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.releaseStrategy.hasText() and self.versioningStrategy.hasText()
This rule reads: independentlyDeployable, releaseStrategy, versioningStrategy, displayName.
Diagnostic and repair
[PIM-DU-003] Independently deployable unit ' ' lacks release or versioning strategy. Suggested fix: define how this unit is versioned, promoted and rolled back independently.
How to fix it:
This is advisory rather than a structural blocker. Decide whether the modeled situation genuinely needs the recommendation; if it does, change the referenced model features so the check evaluates to true and record the rationale when the omission is intentional.
A critique does not necessarily make the model invalid. It is a deliberate quality/readiness signal; disposition it by improving the model, documenting why it is acceptable, or carrying the decision into the review record.
ProdEnvironmentIsProductionLike
Context: PIM!Environment
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:73
Why this rule exists
The rule checks whether prod environment is production like. The environment element provides the relevant evidence through environment class, production like, display name. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-ENV-001] PROD environment ' ' is not marked productionLike.
When it applies
The rule is considered only when the guard below is true. A false guard is intentional: it means this invariant is not relevant to the current variant or modeling situation.
guard : self.environmentClass.enumIs("PROD")
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.productionLike.isTrue()
This rule reads: environmentClass, productionLike, displayName.
Diagnostic and repair
[PIM-ENV-001] PROD environment ' ' is not marked productionLike. Fix: set productionLike to true or choose a non-PROD environmentClass.
How to fix it:
set productionLike to true or choose a non-PROD environmentClass.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
ProdEnvironmentShouldRequireApproval
Context: PIM!Environment
Classification: Advisory critique (warning)
Source: mde/validation/pim/rules/deployment.evl:80
Why this rule exists
The rule checks whether prod environment should require approval. It examines environment class, requires approval, display name. Within this part of the model, services and deployment units can be assembled into environments with a coherent implementation toolchain. The gap is [PIM-ENV-002] PROD environment ' ' does not require approval. Suggested fix: set requiresApproval to true so generated release workflows include a production approval gate. A later transformation, generator, or reviewer would otherwise have to infer the missing decision.
When it applies
The rule is considered only when the guard below is true. A false guard is intentional: it means this invariant is not relevant to the current variant or modeling situation.
guard : self.environmentClass.enumIs("PROD")
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.requiresApproval.isTrue()
This rule reads: environmentClass, requiresApproval, displayName.
Diagnostic and repair
[PIM-ENV-002] PROD environment ' ' does not require approval. Suggested fix: set requiresApproval to true so generated release workflows include a production approval gate.
How to fix it:
This is advisory rather than a structural blocker. Decide whether the modeled situation genuinely needs the recommendation; if it does, change the referenced model features so the check evaluates to true and record the rationale when the omission is intentional.
A critique does not necessarily make the model invalid. It is a deliberate quality/readiness signal; disposition it by improving the model, documenting why it is acceptable, or carrying the decision into the review record.
ProfileHasGenerationBasics
Context: PIM!ImplementationProfile
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:91
Why this rule exists
The rule checks whether profile has generation basics. The implementation profile element provides the relevant evidence through source layout, build command, display name. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-PROFILE-001] Implementation profile ' ' lacks sourceLayout or buildCommand.
When it applies
No guard is defined, so the check runs for every instance of this context in the validated model.
No guard expression is present. Every instance of the context is checked.
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.sourceLayout.hasText() and self.buildCommand.hasText()
This rule reads: sourceLayout, buildCommand, displayName.
Diagnostic and repair
[PIM-PROFILE-001] Implementation profile ' ' lacks sourceLayout or buildCommand. Fix: specify where generated code should be placed and how it is built.
How to fix it:
specify where generated code should be placed and how it is built.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
PackageManagerMatchesRuntimeLanguage
Context: PIM!ImplementationProfile
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:97
Why this rule exists
The rule checks whether package manager matches runtime language. The implementation profile element provides the relevant evidence through package manager fits language, display name, package manager, primary language. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-PROFILE-002] Implementation profile ' ' uses package manager ' ' with runtime language ' '.
When it applies
No guard is defined, so the check runs for every instance of this context in the validated model.
No guard expression is present. Every instance of the context is checked.
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.packageManagerFitsLanguage()
This rule reads: packageManagerFitsLanguage, displayName, packageManager, primaryLanguage.
Diagnostic and repair
[PIM-PROFILE-002] Implementation profile ' ' uses package manager ' ' with runtime language ' '. Fix: choose a compatible package manager, for example NPM/PNPM/YARN for TypeScript/JavaScript, PIP/POETRY for Python, MAVEN/GRADLE for Java, DOTNET for C#, GO_MOD for Go, or CARGO for Rust.
How to fix it:
choose a compatible package manager, for example NPM/PNPM/YARN for TypeScript/JavaScript, PIP/POETRY for Python, MAVEN/GRADLE for Java, DOTNET for C#, GO_MOD for Go, or CARGO for Rust.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.
RuntimeValidationShouldGenerateTypedContracts
Context: PIM!ImplementationProfile
Classification: Advisory critique (warning)
Source: mde/validation/pim/rules/deployment.evl:103
Why this rule exists
The rule checks whether runtime validation should generate typed contracts. It examines generate runtime validation, generate typed contracts. Within this part of the model, services and deployment units can be assembled into environments with a coherent implementation toolchain. The gap is [PIM-PROFILE-003] Runtime validation is requested without typed contract generation. Suggested fix: enable generateTypedContracts so generated validators and handlers share the same schema-derived types. A later transformation, generator, or reviewer would otherwise have to infer the missing decision.
When it applies
The rule is considered only when the guard below is true. A false guard is intentional: it means this invariant is not relevant to the current variant or modeling situation.
guard : self.generateRuntimeValidation.isTrue()
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.generateTypedContracts.isTrue()
This rule reads: generateRuntimeValidation, generateTypedContracts.
Diagnostic and repair
[PIM-PROFILE-003] Runtime validation is requested without typed contract generation. Suggested fix: enable generateTypedContracts so generated validators and handlers share the same schema-derived types.
How to fix it:
This is advisory rather than a structural blocker. Decide whether the modeled situation genuinely needs the recommendation; if it does, change the referenced model features so the check evaluates to true and record the rationale when the omission is intentional.
A critique does not necessarily make the model invalid. It is a deliberate quality/readiness signal; disposition it by improving the model, documenting why it is acceptable, or carrying the decision into the review record.
MembershipMatchesServiceOwnership
Context: PIM!ServiceElementMembership
Classification: Mandatory semantic constraint (error)
Source: mde/validation/pim/rules/deployment.evl:113
Why this rule exists
The rule checks whether membership matches service ownership. The service element membership element provides the relevant evidence through service, element. At this level, services and deployment units can be assembled into environments with a coherent implementation toolchain. Missing evidence would leave an unresolved choice in generated infrastructure. The rule prevents the following failure: [PIM-SVC-006] ServiceElementMembership does not match the service containment parent.
When it applies
No guard is defined, so the check runs for every instance of this context in the validated model.
No guard expression is present. Every instance of the context is checked.
What counts as valid
The model passes when the following EVL check evaluates to true:
check : self.service.isDefined() and self.element.isDefined() and self.service.ownedElements().includes(self.element)
This rule reads: service, element.
Diagnostic and repair
[PIM-SVC-006] ServiceElementMembership does not match the service containment parent. Fix: synchronize membership metadata with ServerlessService val containment.
How to fix it:
synchronize membership metadata with ServerlessService val containment.
A constraint represents a mandatory semantic invariant for this validation profile. Transformation or deployment work should not treat the model as semantically ready while this violation remains unresolved.