Validation & Enrichment

Validation runs in two passes. The structural pass checks that every source and target path resolves to a registered schema attribute, that every datatype is compatible (or that an explicit conversion rule is present), and that every required target attribute is either mapped or explicitly defaulted. Each completed pass writes a `ValidationRunCompleted` entry recording the rule set version, the input ULIDs, and the structured pass/fail result.

The semantic pass annotates each imported mapping with the same MetaModel enrichments described in Entity Enrichment: parent-context (the immediate parent entity in the MetaModel hierarchy), dot-delimited path with optional array notation, abbreviation expansions, and any matching domain-vocabulary tags (HL7 / FHIR / claims / SOX line items / FedRAMP control families, depending on the deployment profile).

Annotations are first-class versioned MetaModel properties, not free-text comments. Each annotation writes `EntityAnnotated` and participates in semantic versioning — so a mapping reviewer in week 12 can see exactly which annotations were in effect when the mapping was first imported, even if the underlying domain vocabulary has since been revised.

Type narrowing, missing required targets, and ambiguous source resolution all surface as Validation findings, classified by severity. Findings of severity `error` block the mapping from advancing to Approval; findings of severity `warning` are recorded against the mapping and require Contributor acknowledgment before draft. A second, separate hard gate then applies at submission time: a mapping version cannot enter the approval workflow until **every schema version it pins** is itself Approved & Published. The two gates compose — clean validation does not bypass the schema-publication gate, and a fully-published schema set does not bypass validation. Either way, the finding (or block) is a ledger entry — there is no in-memory-only validation result.

Enrichment is what makes Predictive Mapping effective on imported spreadsheets. A row that says `dob → patient.date_of_birth` is recognized as an `abbreviation_match` because the abbreviation expansion was annotated at import time; a row that says `id → patient.identifier` is recognized as a `context_hierarchy` match because the parent-context was annotated at import time. Without enrichment, both rows would default to opaque string-similarity heuristics.

The full pipeline — structural validation, semantic enrichment, type-narrowing detection — runs deterministically against the input ULIDs. Re-running validation at the same ULIDs is guaranteed to produce the same findings. That property is what makes a clean import defensible against FedRAMP AU-12 (audit record generation) and ISO 27001 A.8.15 (logging) without retroactive justification.