Map

Mapping is where the bulk of human authorship happens, and where most of the ledger volume comes from. Every draft of every mapping, every edit by every Contributor, every Reviewer comment, and every Semantic Match accept/reject is its own ledger entry — not a row in a separate audit table that gets out of sync, but a primary artifact of the mapping itself.

The first save of a mapping writes `MappingDrafted`. Every subsequent save writes `MappingRevised` carrying the prior payload hash, the new payload hash, and the actor's role at time of action. Field-level changes inside a draft write `FieldMappingChanged` so a reviewer can see not just that the mapping was edited but exactly which attribute pair changed. There is no 'silent save' — an autosave is still a `MappingRevised` entry.

Semantic Match suggestions are first-class citizens of the chain. Each invocation of the Predictive Mapping `semantic-match` edge function writes `SemanticSuggestionReturned` carrying the model identifier, the threshold profile version, the algorithm class (exact_match, synonym_match, abbreviation_match, context_hierarchy, or domain_equivalence), and the integer confidence score. Each accept or reject writes the corresponding entry. A reviewer can replay any historical mapping decision under HIPAA §164.312(b) and 21 CFR Part 11 §11.10(e) and prove which suggestion the human chose.

Reviewer comments are not stored in a side channel. Each `ReviewerCommented` entry references the mapping ULID, the field path the comment is anchored to, the commenter's role at time of action, and the canonical comment text hash. A comment cannot be silently edited later — an edit writes a new entry chained to the old one. This is what allows a SOX §404 walkthrough to ask 'who raised an objection to this transformation?' and get a complete answer.

The mapping draft can be exported, validated, and impact-analyzed before it is ever submitted for approval. Every exported draft writes `ArtifactExported` (with `draft=true` in the entry payload) so a stakeholder review of a draft is itself an auditable event. Drafts cannot be promoted to production-bound exports — that path requires the Govern phase.

When a Contributor is satisfied with a mapping, they sign it as a draft (`DraftSaved` with the Contributor's electronic signature) and request approval (`ApprovalRequested`). The mapping is now ready for the Govern phase. Up to this point, no production-bound artifact has been emitted; everything that exists lives in the draft side of the workflow.

**Schema Publication Gate (hard).** A mapping version cannot be submitted for approval until **every schema version it pins** — every source schema version and every target schema version — has itself completed approval and been Published. Drafting and editing a mapping against in-flight schemas is allowed; submission is not. An attempted submission against any unpublished pinned schema is rejected server-side and writes `MappingSubmitBlocked` carrying the offending schema_id and current status. The canonical lifecycle order is: source schemas Published → target schemas Published → mapping submitted → mapping Published. Approval is never parallel.