EVL semantic validation reference

This reference explains the semantic validation layer of the three serverless DSMLs. The Emfatic/Ecore metamodel defines what can be represented structurally; EVL defines whether a structurally loadable model makes sense as a business model, provider-independent architecture, or AWS deployment design.

What EVL contributes

Structural conformance can tell us that a WorkflowStep has an orderIndex of the right Ecore type. It cannot tell us that the workflow has an entry point, that a task invokes exactly one action, or that a terminal state has no successor. Those are semantic relationships and assumptions; EVL is where this project makes them explicit.

Every entry below is one actual constraint or critique from mde/validation/. The reference keeps the source guard, check, diagnostic, and referenced features visible so a modeller can move from explanation to authoritative implementation without ambiguity.

Constraint versus critique

EVL construct	Meaning in this project	What to do with a finding
`constraint`	A mandatory semantic invariant. The model is not semantically acceptable for that profile while it fails.	Correct the model or its relationships; do not treat a green structural check as a substitute.
`critique`	An advisory weakness, readiness concern, or design-quality recommendation. The model can remain valid, but the omission must be conscious.	Improve it, or record a reasoned disposition during review.

Guards are applicability boundaries

A guard does not make a rule weaker; it says which variant the rule is about. For example, a production-only encryption critique should not report on a development resource, and a retry rule should not demand a policy from a model element that never retries. When a guard is false, the rule is intentionally not evaluated.

Validation entry points

Profile	Entry EVL	Scope	Rules
Shared kernel	`mde/validation/shared/kernel-constraints.evl`	Identity and traceability invariants imported by the level profiles	2
CIM	`mde/validation/cim/cim-semantic-validation.evl`	Business intent, domain, behavior, process, policy, governance, and readiness	158
PIM	`mde/validation/pim/pim-semantic-validation.evl`	Provider-independent serverless architecture, contracts, integration, security, workflow, policy, and readiness	185
AWS PSM	`mde/validation/psm/psm-semantic-validation.evl`	AWS resources, SAM/CloudFormation, Lambda, APIs, events, storage, security, workflow, networking, and relationships	201

The level entry files import the shared kernel rules and their concern-specific modules. Validate a model after structural parsing/conformance and before the transformation or generation gate that depends on its semantics.

Rule map

Area	What the rules protect	Reference	Rules
CIM: Behavior	Behavior rules distinguish commands, queries, events, errors, and conditions. Their purpose is to preserve business meaning at the point where it is easiest to lose: before functions, routes, event channels, retries, and authorization policies are generated.	CIM: Behavior	23
CIM: Core Kernel Trace	These rules make a CIM model a coherent starting point for refinement. They require a semantic core, protect model identity and origin, and stop provider vocabulary from leaking into the computation-independent language.	CIM: Core Kernel Trace	12
CIM: Domain Data	Domain-data rules prevent business concepts from becoming attractive but unusable nouns. They protect identity and lifecycle meaning, aggregate boundaries, equality of value objects, information typing, privacy classification, and the evidence needed to turn domain data into PIM schemas and stores.	CIM: Domain Data	29
CIM: Governance Readiness	Governance rules turn non-functional, security, privacy, compliance, risk, and readiness concerns into reviewable model facts. They keep a model from being declared ready while a known blocker has no owner, recommendation, evidence, or decision.	CIM: Governance Readiness	27
CIM: Organization Intent	Organization and intent rules ask whether the business problem is specific enough to guide architecture. Requirements need observable fit, goals need measurable success, actors and systems need explicit trust expectations, and capabilities need ownership and behavior.	CIM: Organization Intent	32
CIM: Process Policy	Process and policy rules check that a business journey has a real beginning, completion, responsibility, branching logic, timing, and recovery story. They are deliberately stricter about meaning than about implementation: a process can be technology-neutral, but it cannot be ownerless or impossible to complete.	CIM: Process Policy	35
PIM: API	API rules make a provider-independent interface internally coherent: routes are unique and well formed, each has one backend, protected operations have authorization, and validation settings are backed by schemas. Critiques add the consumer-facing documentation and error behavior that makes an API usable rather than merely callable.	PIM: API	13
PIM: Compute	Compute rules ensure that every function has a responsibility, contract, reachability path, and compatible state behavior. They also surface the operational consequences of external calls, public exposure, duration, idempotency, and event publication.	PIM: Compute	13
PIM: Contracts	Contract rules protect the boundaries through which functions, APIs, events, and messages communicate. They require meaningful input/output shape, typed fields, compatible versions, and explicit handling for sensitive or externally sourced schemas.	PIM: Contracts	15
PIM: Core	PIM core rules protect the provider-independent architecture's identity, portability, naming, traceability, and explanation. They are the guard against a PIM that is structurally valid but already assumes an AWS resource or has lost its business origin.	PIM: Core	9
PIM: Data	Data rules connect stores to schemas and access patterns, then connect those choices back to functions and policies. They make transactionality, consistency, indexes, retention, backup, streams, and privacy explicit before a DynamoDB or S3 design is generated.	PIM: Data	21
PIM: 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.	PIM: Deployment	15
PIM: Integration	Integration rules ensure channels, queues, topics, schedules, subscriptions, buses, and flows say enough about delivery, routing, ordering, replay, dead letters, and ownership to be mapped safely to AWS messaging and event services.	PIM: Integration	27
PIM: Policies	Policy rules turn resilience, timeout, idempotency, rate, batching, ordering, caching, backup, retention, cost, observability, CORS, and data-protection intent into bounded architecture decisions rather than provider defaults.	PIM: Policies	25
PIM: Readiness	PIM readiness rules separate a model that can be transformed from one that is ready to be deployed or called production-ready. They reconcile checks, findings, manual decisions, blockers, and remediation rather than treating a single status flag as evidence.	PIM: Readiness	6
PIM: Security Config External	Security, configuration, and external-system rules stop credentials, identity assumptions, authorization logic, and provider endpoints from remaining implicit. The rules are especially concerned with secret references, least privilege, federation, and environment-specific ownership.	PIM: Security Config External	21
PIM: Workflow	Workflow rules protect the PIM execution graph: it must have entry and termination, reachable steps, valid transitions, unambiguous task actions, recoverable errors, and explicit compensation where the business needs it.	PIM: Workflow	20
AWS PSM: API	API Gateway rules verify that the concrete API graph has routes, integrations, authorizers, certificates, stages, logs, metrics, throttles, and credentials that agree with one another. They catch provider-level omissions that a PIM API contract cannot see.	AWS PSM: API	21
AWS PSM: Compute	Lambda rules check the parts of a function that AWS cannot safely infer: execution role, code location, runtime/handler pairing, package form, resource limits, environment-secret handling, event-source bounds, destinations, logging, and production safeguards.	AWS PSM: Compute	32
AWS PSM: Core	AWS PSM core rules protect the deployment graph and CloudFormation/SAM safety model: stages and stacks must exist, logical IDs must be valid and unique, imports must be explicit, expressions must have compatible shapes, and production resources must carry the required governance metadata.	AWS PSM: Core	40
AWS PSM: Events	EventBridge rules validate the provider-specific event graph: patterns and schedules are not mixed accidentally, targets are complete and unique, roles and connections match their integration type, and retry/dead-letter behavior is not omitted from critical delivery paths.	AWS PSM: Events	14
AWS PSM: Identity	Cognito rules protect production authentication posture and OAuth completeness. They make MFA, deletion protection, callback URLs, user-existence behavior, and unauthenticated identity review explicit rather than silently accepting an insecure default.	AWS PSM: Identity	6
AWS PSM: Messaging	SQS and SNS rules enforce AWS naming, FIFO semantics, timing ranges, redrive behavior, encryption expectations, subscription targets, and filter completeness. They protect the operational contract that sits below the provider-independent channel model.	AWS PSM: Messaging	12
AWS PSM: Networking	Networking rules verify that VPC attachments have subnets and security groups, modeled IDs do not contradict typed references, private connectivity assumptions are supported, DNS is enabled, and public administrative ingress is reviewed.	AWS PSM: Networking	6
AWS PSM: Observability	CloudWatch rules require alarms and metrics to have the information needed to act on them. Production observability is treated as an operational control: a metric without a threshold or an alarm without an action is not meaningful protection.	AWS PSM: Observability	6
AWS PSM: Relationships	Relationship-view rules check that the generated integration picture agrees with the deployable resources and permissions it claims to summarize. They are consistency checks across resources, not substitutes for the resource-specific rules.	AWS PSM: Relationships	9
AWS PSM: Security	IAM, KMS, Secrets Manager, and SSM rules enforce the security properties that are too important to leave to template conventions: trust and permission statements, least privilege evidence, key rotation, secret sources, secure parameter types, and safe production defaults.	AWS PSM: Security	17
AWS PSM: Storage	DynamoDB and S3 rules validate key coverage, capacity-mode consistency, index definitions, TTL/encryption/backup choices, public-access blocking, notifications, and replication. These checks are aimed at preventing deployable templates that still lose or expose data.	AWS PSM: Storage	18
AWS PSM: Workflow	Step Functions and ASL rules protect the executable state graph. They verify definition sources, entry and terminal states, state naming, task targets, JSONPath/JSONata boundaries, waits, choices, retries, and catches so a generated state machine is not merely syntactically shaped but operationally startable.	AWS PSM: Workflow	20
Shared kernel: Kernel Constraints	The shared kernel rules protect invariants that every DSML relies on: stable identity, traceability, and a usable correspondence between model elements. They run in each level's entry profile, so a model that is meaningful at CIM is still required to remain addressable and traceable after refinement.	Shared kernel: Kernel Constraints	2

How this relates to the assistant

Explicit model-validation workflows may run EVL and expose these semantic findings. Chatbot assistant apply, repair, and commit paths use structural Ecore/EMF conformance only through ModelService.validateStructural(...); they must not invoke EVL as their mutation gate. This boundary keeps semantic review a deliberate user/model validation action rather than an implicit side effect of assistant mutation.