Schemas and contracts

Contracts make payload shape and compatibility explicit for APIs, events, messages, and function boundaries.

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

`Schema`

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

Direct supertypes: TraceableElement, 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
`semanticVersion`	`String` [1]	Records the compatibility/version marker for semantic version for the schema. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `SchemaVersionShouldBeSemver` (schema version should be semver) in `mde/validation/pim/rules/contracts.evl` the value must be present and non-blank. Transformation role: ETL rule `BusinessError2ErrorSchema` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Schema`. ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Schema`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `1.0.0`.
`additionalPropertiesAllowed`	`Boolean` [1]	Records whether additional properties allowed applies to schema. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `BusinessError2ErrorSchema` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Schema`. ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Schema`.	Either `true` or `false`. Example: `true`.
`generatedFromCimInformation`	`Boolean` [1]	Records whether generated from cim information applies to schema. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Schema`. ETL rule `Entity2Schema` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `Schema`.	Either `true` or `false`. Example: `false`.
`externalSchemaUri`	`String` [1]	Records URI/URL from which external schema is obtained for schema. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `SchemaHasFieldsUnlessExternal` (schema has fields unless external) in `mde/validation/pim/rules/contracts.evl` the value must be present and non-blank. `ExternalSchemaShouldStateCompatibility` (external schema should state compatibility) in `mde/validation/pim/rules/contracts.evl` the value must be present and non-blank. Transformation role: ETL rule `Schema2StructuredDocument` in `mde/transformations/pim-to-awspsm/contracts-external-policy.etl` assigns or materializes this feature while refining `Schema`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `https://example.com/orders`.
`schemaKind`	`SchemaKind` [1]	For a schema, the model records the controlled classification or strategy represented by schema kind. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Transformation role: ETL rule `BusinessError2ErrorSchema` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Schema`. ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Schema`.	Exactly one of: `REQUEST`, `RESPONSE`, `ERROR`, `EVENT`, `MESSAGE`, `ENTITY`, `VALUE_OBJECT`, `READ_MODEL`, `CONFIGURATION`. Example: `REQUEST`.
`compatibility`	`SchemaCompatibility` [1]	Records the controlled classification or strategy for compatibility in the schema. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `SchemaVersionShouldBeSemver` (schema version should be semver) in `mde/validation/pim/rules/contracts.evl` the rule's diagnostic or remediation guidance refers to this feature. `ExternalSchemaShouldStateCompatibility` (external schema should state compatibility) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `BusinessError2ErrorSchema` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Schema`. ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `Schema`.	Exactly one of: `NONE`, `BACKWARD`, `FORWARD`, `FULL`. Example: `NONE`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`fields` → `SchemaField`	containment, [*]; opposite `ownerSchema`	Contains the schema field element(s) that make up this schema; the contained objects belong to this model element.
`constraints` → `SchemaConstraint`	containment, [*]; opposite `ownerSchema`	Contains the schema constraint element(s) that make up this schema; the contained objects belong to this model element.

`SchemaField`

Represents schema 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
`required`	`Boolean` [1]	Records whether required applies to schema field. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `FieldLengthBoundsAreValid` (field length bounds are valid) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. `RequiredNullableFieldNeedsRationale` (required nullable field needs rationale) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `SchemaField`.	Either `true` or `false`. Example: `true`.
`nullable`	`Boolean` [1]	For a schema field, the model records whether nullable applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `FieldLengthBoundsAreValid` (field length bounds are valid) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. `RequiredNullableFieldNeedsRationale` (required nullable field needs rationale) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `SchemaField`.	Either `true` or `false`. Example: `false`.
`array`	`Boolean` [1]	For a schema field, the model records whether array applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `SchemaField`. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/contracts.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/iam.eol`.	Either `true` or `false`. Example: `false`.
`format`	`String` [1]	Stores the serialization/content format for format on the schema field. 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/contracts.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/paths.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Schema Field Format`.
`defaultValue`	`String` [1]	Records the default value value for the schema field. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `SensitiveFieldShouldNotExposeExamplesOrDefaults` (sensitive field should not expose examples or defaults) in `mde/validation/pim/rules/contracts.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: `READY`.
`example`	`String` [1]	Records the example value for schema field. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `SensitiveFieldIsClassified` (sensitive field is classified) in `mde/validation/pim/rules/contracts.evl` the rule's diagnostic or remediation guidance refers to this feature. `SensitiveFieldShouldNotExposeExamplesOrDefaults` (sensitive field should not expose examples or defaults) in `mde/validation/pim/rules/contracts.evl` the value must be present and non-blank. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/awspsm2artifacts.egx`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/paths.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Schema Field Example`.
`minLength`	`Integer` [1]	Records the min length value for the schema field. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `FieldLengthBoundsAreValid` (field length bounds are valid) in `mde/validation/pim/rules/contracts.evl` the related value or object must be explicitly provided.	A numeric `Integer` value; use the unit or boundary documented for this attribute. Example: `1`.
`maxLength`	`Integer` [1]	Records the max length value for schema field. 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. Semantic validation: `FieldLengthBoundsAreValid` (field length bounds are valid) in `mde/validation/pim/rules/contracts.evl` the related value or object must be explicitly provided.	A numeric `Integer` value; use the unit or boundary documented for this attribute. Example: `1`.
`pattern`	`String` [1]	Records the validation pattern for pattern for the schema field. This keeps the decision explicit even when the element's class or relationships remain unchanged. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/validation.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `^[A-Z][A-Za-z0-9_-]*$`.
`minimum`	`String` [1]	Records the minimum value for schema field. 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: `Schema Field Minimum`.
`maximum`	`String` [1]	Records the maximum value for the schema field. 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: `Schema Field Maximum`.
`personalData`	`Boolean` [1]	Records the data-sensitivity classification for personal data in the schema field. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `SensitiveFieldIsClassified` (sensitive field is classified) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. `SensitiveFieldShouldNotExposeExamplesOrDefaults` (sensitive field should not expose examples or defaults) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`sensitiveData`	`Boolean` [1]	Records the data-sensitivity classification for sensitive data in schema field. It keeps privacy, encryption, and access decisions explicit during review and transformation, so later steps do not have to infer them. Semantic validation: `SensitiveFieldIsClassified` (sensitive field is classified) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. `SensitiveFieldShouldNotExposeExamplesOrDefaults` (sensitive field should not expose examples or defaults) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`secretValue`	`Boolean` [1]	For a schema field, the model records whether secret value applies. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `SensitiveFieldIsClassified` (sensitive field is classified) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. `SensitiveFieldShouldNotExposeExamplesOrDefaults` (sensitive field should not expose examples or defaults) in `mde/validation/pim/rules/contracts.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`.
`classification`	`String` [1]	Records the data-sensitivity classification for classification in schema field. It keeps privacy, encryption, and access decisions explicit during review and transformation, so later steps do not have to infer them. Semantic validation: `SensitiveFieldIsClassified` (sensitive field is classified) in `mde/validation/pim/rules/contracts.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`.
`descriptionForConsumers`	`String` [1]	Records the human explanation of description for consumers for the schema field. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `RequiredNullableFieldNeedsRationale` (required nullable field needs rationale) in `mde/validation/pim/rules/contracts.evl` the value must be present and non-blank. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `SchemaField`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Processes confirmed orders for the owning capability.`.
`fieldType`	`FieldType` [1]	Records the controlled classification or strategy for field type in the schema field. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `EnumFieldHasLiterals` (enum field has literals) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. `ObjectFieldHasObjectSchema` (object field has object schema) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `SchemaField`.	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
`cardinality` → `Cardinality`	containment, [?]	Contains the cardinality element(s) that make up this schema field; the contained objects belong to this model element.
`enumValues` → `SchemaEnumLiteral`	containment, [*]; opposite `field`	Contains the schema enum literal element(s) that make up this schema field; the contained objects belong to this model element.
`constraints` → `SchemaValidationConstraint`	containment, [*]	Contains the schema validation constraint element(s) that make up this schema field; the contained objects belong to this model element.
`arrayItem` → `SchemaField`	containment, [?]	Contains the schema field element(s) that make up this schema field; the contained objects belong to this model element.
`mapValue` → `SchemaField`	containment, [?]	Contains the schema field element(s) that make up this schema field; the contained objects belong to this model element.
`ownerSchema` → `Schema`	reference; read-only, [1]; opposite `fields`	References the schema element(s) used as owner schema by this schema field; the target may be shared elsewhere in the model.
`objectSchema` → `Schema`	reference, [?]	References the schema element(s) used as object schema by this schema field; the target may be shared elsewhere in the model.

`SchemaEnumLiteral`

Represents schema enum literal 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
`literal`	`String` [1]	For a schema enum literal, the model records the literal value. 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/cfn.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/validation.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Schema Enum Literal Literal`.
`displayName`	`String` [1]	The human-facing label used when the modeler needs a readable name distinct from the technical identity. Here it is attached to the schema enum literal, so the shared meaning travels with this particular model element. 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/naming.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `SchemaEnumLiteralExample`.
`deprecationReason`	`String` [1]	Records reasoning behind deprecation reason for schema enum literal. It keeps design review and decision traceability 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: `Schema Enum Literal Deprecation Reason`.

Relationships

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

`SchemaValidationConstraint`

Represents schema validation constraint 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
`keyword`	`String` [1]	Stores the keyword value on the schema validation constraint. 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`.
`value`	`String` [1]	Stores the value value on the schema validation constraint. 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`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/iam.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `READY`.
`message`	`String` [1]	Stores the human explanation of message on the schema validation constraint. The field records human review and generated guidance 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.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Order could not be completed.`.
`severity`	`Severity` [1]	For a schema validation constraint, the model records the controlled classification or strategy represented by severity. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. The repository contains no direct EVL rule, ETL assignment, or artifact-generator read for this declared field. For now, it remains a model-level fact for review and future refinement.	Exactly one of: `INFO`, `WARNING`, `ERROR`, `CRITICAL`, `BLOCKER`. Example: `INFO`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`expression` → `Expression`	containment, [?]	Contains the expression element(s) that make up this schema validation constraint; the contained objects belong to this model element.

`SchemaConstraint`

Represents schema constraint 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
`expressionLanguage`	`String` [1]	Stores the expression language value on the schema constraint. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `SchemaConstraintHasExpressionAndMessage` (schema constraint has expression and message) in `mde/validation/pim/rules/contracts.evl` the value must be present and non-blank. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `SchemaConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`expression`	`String` [1]	Stores the expression or rule that governs expression on the schema constraint. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `SchemaConstraintHasExpressionAndMessage` (schema constraint has expression and message) in `mde/validation/pim/rules/contracts.evl` the value must be present and non-blank. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `SchemaConstraint`. Generation role: The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/cfn.eol`. The artifact generator references this feature in `mde/generation/awspsm-to-artifacts/lib/validation.eol`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`message`	`String` [1]	Records the human explanation of message for the schema constraint. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `SchemaConstraintHasExpressionAndMessage` (schema constraint has expression and message) in `mde/validation/pim/rules/contracts.evl` the value must be present and non-blank. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `SchemaConstraint`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `Order could not be completed.`.
`severity`	`Severity` [1]	Records controlled classification or strategy represented by severity for schema constraint. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Transformation role: ETL rule `DomainRelationship2SchemaReference` in `mde/transformations/cim-to-pim/domain-data.etl` assigns or materializes this feature while refining `SchemaConstraint`.	Exactly one of: `INFO`, `WARNING`, `ERROR`, `CRITICAL`, `BLOCKER`. Example: `INFO`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`expressionModel` → `Expression`	containment, [?]	Contains the expression element(s) that make up this schema constraint; the contained objects belong to this model element.
`ownerSchema` → `Schema`	reference; read-only, [1]; opposite `constraints`	References the schema element(s) used as owner schema by this schema constraint; the target may be shared elsewhere in the model.

`FunctionContract`

Represents function contract 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
`contractVersion`	`String` [1]	For a function contract, the model records the compatibility/version marker for contract version. 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: `1.0`.
`validatesInput`	`Boolean` [1]	Records whether validates input applies to function contract. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `InputValidationRequiresInputSchema` (input validation requires input schema) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`validatesOutput`	`Boolean` [1]	Records whether validates output applies to function contract. The field records an explicit architectural or governance decision as an explicit, reviewable input. Semantic validation: `OutputValidationRequiresOutputSchema` (output validation requires output schema) in `mde/validation/pim/rules/contracts.evl` the feature participates in a semantic validation condition.	Either `true` or `false`. Example: `false`.
`correlationIdField`	`String` [1]	Records the data location or endpoint represented by correlation id field for the function contract. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `CorrelationIdFieldShouldExistInSchema` (correlation id field should exist in schema) in `mde/validation/pim/rules/contracts.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: `Function Contract Correlation Id Field`.
`causationIdField`	`String` [1]	For a function contract, the model records the data location or endpoint represented by causation id field. 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: `Function Contract Causation Id Field`.
`idempotencyKeyField`	`String` [1]	Stores the data location or endpoint represented by idempotency key field on the function contract. The field keeps the model explicit and reviewable during review and transformation instead of leaving the decision to an inferred default. Semantic validation: `IdempotencyKeyFieldShouldExistInSchema` (idempotency key field should exist in schema) in `mde/validation/pim/rules/contracts.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`.
`authContextRequired`	`Boolean` [1]	For a function contract, the model records whether auth context required 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: `true`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`inputSchema` → `Schema`	reference, [?]	References the schema element(s) used as input schema by this function contract; the target may be shared elsewhere in the model.
`outputSchema` → `Schema`	reference, [?]	References the schema element(s) used as output schema by this function contract; the target may be shared elsewhere in the model.
`errorSchemas` → `Schema`	reference, [*]	References the schema element(s) used as error schemas by this function contract; the target may be shared elsewhere in the model.
`emittedEvents` → `EventType`	reference, [*]	References the event type element(s) used as emitted events by this function contract; the target may be shared elsewhere in the model.

`ApiContract`

Represents api contract 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
`publicVersion`	`String` [1]	Records compatibility/version marker for public version for api contract. 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`.
`backwardCompatible`	`Boolean` [1]	Records whether backward compatible applies to api contract. 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`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`requestSchemas` → `Schema`	reference, [*]	References the schema element(s) used as request schemas by this api contract; the target may be shared elsewhere in the model.
`responseSchemas` → `Schema`	reference, [*]	References the schema element(s) used as response schemas by this api contract; the target may be shared elsewhere in the model.
`errorSchemas` → `Schema`	reference, [*]	References the schema element(s) used as error schemas by this api contract; the target may be shared elsewhere in the model.

`EventEnvelope`

Represents event envelope 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
`eventIdField`	`String` [1]	Records the data location or endpoint represented by event id field for the event envelope. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `EnvelopeShouldCarryCorrelationFields` (envelope should carry correlation fields) in `mde/validation/pim/rules/integration.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: `Event Envelope Event Id Field`.
`eventTypeField`	`String` [1]	For a event envelope, the model records the data location or endpoint represented by event type field. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Semantic validation: `EnvelopeShouldCarryCorrelationFields` (envelope should carry correlation fields) in `mde/validation/pim/rules/integration.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: `BUSINESS`.
`sourceField`	`String` [1]	Records origin/source selected for source field for event envelope. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `EnvelopeShouldCarryCorrelationFields` (envelope should carry correlation fields) in `mde/validation/pim/rules/integration.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: `Event Envelope Source Field`.
`timeField`	`String` [1]	Records the data location or endpoint represented by time field for the event envelope. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `EnvelopeShouldCarryCorrelationFields` (envelope should carry correlation fields) in `mde/validation/pim/rules/integration.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: `Event Envelope Time Field`.
`versionField`	`String` [1]	Stores the compatibility/version marker for version field on the event envelope. The field records compatibility and contract evolution as an explicit, reviewable input. Semantic validation: `EnvelopeShouldCarryCorrelationFields` (envelope should carry correlation fields) in `mde/validation/pim/rules/integration.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`.
`correlationIdField`	`String` [1]	Records the data location or endpoint represented by correlation id field for the event envelope. This keeps the decision explicit even when the element's class or relationships remain unchanged. Semantic validation: `EnvelopeShouldCarryCorrelationFields` (envelope should carry correlation fields) in `mde/validation/pim/rules/integration.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: `Event Envelope Correlation Id Field`.
`causationIdField`	`String` [1]	For a event envelope, the model records the data location or endpoint represented by causation id field. 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: `Event Envelope Causation Id Field`.
`subjectField`	`String` [1]	For a event envelope, the model records the data location or endpoint represented by subject field. 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: `Event Envelope Subject Field`.
`metadataRequired`	`Boolean` [1]	Records whether metadata required applies to event envelope. 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: `true`.

Relationships

This class declares no direct relationships.

`EventType`

Represents event type 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
`semanticName`	`String` [1]	Records stable name/key/code used for semantic name for event type. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `EventType`. ETL rule `EventType2StructuredDocument` in `mde/transformations/pim-to-awspsm/contracts-external-policy.etl` assigns or materializes this feature while refining `EventType`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `EventTypeExample`.
`version`	`String` [1]	Stores the compatibility/version marker for version on the event type. The field records compatibility and contract evolution as an explicit, reviewable input. Semantic validation: `PersonalDataEventSchemaIsClassified` (personal data event schema is classified) in `mde/validation/pim/rules/integration.evl` the feature participates in a semantic validation condition. `EventTypeShouldHaveVersionAndSource` (event type should have version and source) in `mde/validation/pim/rules/integration.evl` the value must be present and non-blank. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `EventType`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `1.0`.
`sourceDomain`	`String` [1]	Records origin/source selected for source domain for event type. It keeps this decision explicit during review and transformation, so later steps do not have to infer it. Semantic validation: `EventTypeShouldHaveVersionAndSource` (event type should have version and source) in `mde/validation/pim/rules/integration.evl` the value must be present and non-blank. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `EventType`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `orders.example.com`.
`subjectExpression`	`String` [1]	For a event type, the model records the expression or rule that governs subject expression. Keeping the fact with its owning element lets validation and refinement inspect it before artifact generation. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `EventType`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `$.status == 'READY'`.
`orderingKey`	`String` [1]	Records the precedence value for ordering key for the event type. This keeps the decision explicit even when the element's class or relationships remain unchanged. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `EventType`.	A free-form `String`, subject to this class's semantic meaning and any EVL constraints. Example: `orderId`.
`externalEvent`	`Boolean` [1]	Records whether external event applies to event type. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `ExternalOrReplayableEventShouldHaveEnvelope` (external or replayable event should have envelope) in `mde/validation/pim/rules/integration.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `EventType`.	Either `true` or `false`. Example: `false`.
`auditEvent`	`Boolean` [1]	Records whether audit event applies to event type. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `ExternalOrReplayableEventShouldHaveEnvelope` (external or replayable event should have envelope) in `mde/validation/pim/rules/integration.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `EventType`.	Either `true` or `false`. Example: `true`.
`replayable`	`Boolean` [1]	Records whether replayable applies to event type. It preserves an explicit architectural or governance decision through review and transformation, so later steps do not have to infer it. Semantic validation: `EventTypeShouldHaveVersionAndSource` (event type should have version and source) in `mde/validation/pim/rules/integration.evl` the feature participates in a semantic validation condition. `ExternalOrReplayableEventShouldHaveEnvelope` (external or replayable event should have envelope) in `mde/validation/pim/rules/integration.evl` the feature participates in a semantic validation condition. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `EventType`.	Either `true` or `false`. Example: `false`.
`containsPersonalData`	`Boolean` [1]	Records the data-sensitivity classification for contains personal data in event type. It keeps privacy, encryption, and access decisions explicit during review and transformation, so later steps do not have to infer them. Transformation role: ETL rule `BusinessEvent2EventType` in `mde/transformations/cim-to-pim/behavior-contracts.etl` assigns or materializes this feature while refining `EventType`.	Either `true` or `false`. Example: `false`.

Relationships

Relationship	Kind and multiplicity	Meaning in the model
`envelope` → `EventEnvelope`	containment, [?]	Contains the event envelope element(s) that make up this event type; the contained objects belong to this model element.
`schema` → `Schema`	reference, [1]	References the schema element(s) used as schema by this event type; the target may be shared elsewhere in the model.
`producedBy` → `FunctionTarget`	reference, [*]	References the function target element(s) used as produced by by this event type; the target may be shared elsewhere in the model.
`consumedBy` → `FunctionTarget`	reference, [*]	References the function target element(s) used as consumed by by this event type; the target may be shared elsewhere in the model.