Entity Enrichment
Annotations are first‑class versioned properties of the MetaModel. Every enrichment writes EntityAnnotated to the ledger, so the parent‑context, abbreviation, and domain vocabulary that a Semantic Match suggestion depended on can be replayed exactly as it was at the moment of decision.
When a schema is imported, every attribute is annotated with structural metadata: parent-entity context, dot-delimited path, optional array notation (e.g. orders[0].lines[1].item), and any semantic tags carried in the source.
These annotations are what allow the Semantic Match API to resolve cases where the attribute name alone is ambiguous. The 'context_hierarchy' algorithm class, in particular, depends on the parent entity to disambiguate fields like 'id', 'name', or 'date'.
Domain vocabulary tags drive the 'domain_equivalence' algorithm class, which recognizes that 'client' and 'customer', 'subject' and 'patient', or 'encounter' and 'visit' refer to the same concept inside a given regulated domain (HL7 / FHIR / claims).
Abbreviation handling drives the 'abbreviation_match' class — pairing 'dob' with 'date_of_birth', 'qty' with 'quantity', 'addr' with 'address' — without requiring a hand-maintained synonym dictionary.
Every enrichment — whether deterministic or model‑proposed — writes an `EntityAnnotated` entry to the ULID-keyed audit ledger. The MetaModel stores annotations as first-class versioned properties so they participate in semantic versioning, draft/publish, and the same hash chain as the mappings they inform.
Audit ledger entries written by this feature
Each action in this feature appends one of the following entry types to the ULID‑keyed, SHA‑256 hash‑chained audit ledger. A reviewer can replay the chain to reconstruct exactly what happened, when, and under which role.
EntityAnnotatedAnnotationRevisedDomainVocabularyAppliedRelated glossary terms
Definitions for the technical, regulatory, and standards terms referenced on this page. Each link opens the term in the full glossary.
Open the full glossary